MCP individual permission controls unresponsive despite canConfigure: true

[dlphoto-ctrl]

Bug report — MCP permission controls not working

I'm requesting help from the Paperclip maintainers with an issue preventing me from configuring individual MCP action permissions.

What happens

I have an installed Home Assistant MCP connection in Paperclip, with 40 discovered actions (32 Read and 8 Write).

All actions currently show Off.

When I try to change the individual Get Entity State action from Off to Ask first, nothing happens. The permission remains Off, and a prohibited cursor appears.

This happens in both Brave and Microsoft Edge.

Expected behaviour

I should be able to change one individual MCP action to Ask first, without enabling all 32 Read actions or any Write actions.

What has already been verified

• My account has organisation Owner and instance Administrator access.
• The permissions API returns HTTP 200 with capabilities.canConfigure: true.
• The bulk permissions dropdown opens, but the individual permission control does not work.
• The problem occurs in two different browsers.
• The installation runs in Docker on a UGREEN NAS.

Technical investigation

The following frontend files were examined:

• PermissionsPanel.tsx
• AppDetail.tsx
• Tooltip wrappers and CSS
• Installed frontend bundle index-YJY9oyby.js

Isolated component and mocked save tests passed, but the reported behaviour has not been reproduced in an automated browser environment.

A separate reproduction package has been prepared containing source hashes, test evidence, a mocked browser harness and disposable-database instructions.

The exact cause remains unknown.

Help requested

Could a Paperclip maintainer please investigate why individual MCP permission controls are unresponsive even when the API reports canConfigure: true?

I need to enable specific read-only actions while leaving all write actions disabled.

I would appreciate guidance on a verified fix rather than further speculative troubleshooting.

No production permissions, deployment settings or credentials have been changed as part of this investigation.

[Medamineelkhattabi]

In the current source the per-action control can't be blocked on its own. The per-row Off / Ask first / Allowed buttons and the "Set all" dropdown are disabled by the same flag, the page's save-in-progress state, and while it's set the section header shows "Saving…". So the not-allowed cursor means a save is running (normally the one your click just started), and the real question is why that save doesn't stick. The response to that request will name the cause, and you can set one action through the API in the meantime (below).

I checked v2026.1106.0 (the latest tag) and v2026.1023.0 (the latest on the day you posted). PermissionsPanel.tsx and AppDetail.tsx are byte-identical in both, and PermissionsPanel.tsx is unchanged on master too.

• Both controls are only rendered when capabilities.canConfigure is true, and both get disabled={pending}, where pending is the page's "save in progress" flag (ActionsSection props, Set all select, row buttons).
• There is no category-level lock, no per-action flag, and no pointer-events wrapper. The Radix tooltip trigger just passes the click through. The prohibited cursor comes from disabled:cursor-not-allowed on the row button (L530-L535). That only applies while pending is true, and when it is, the Set all dropdown is disabled too.
• If you really see the not-allowed cursor on a row while "Set all" opens at the same moment, with no "Saving…", your container isn't running this code. Check the image tag or version first.
• pending goes true in onMutate and back to false in onSettled of the save mutation. A rejected save shows a "Couldn't save that" toast with the server's error text (AppDetail.tsx L289-L324).

I ran the component in vitest with 32 Read and 8 Write actions, all Off. When idle, "Get Entity State: Ask first" is enabled, and clicking it calls the setter once with (["<that id>"], "ask"). With pending true, the row buttons and both Set all selects are disabled together. The existing AppDetail tests for the three-way toggle also pass and show the click posting to the save endpoint.

What the click sends: one POST /api/companies/{companyId}/tools/apps/{connectionId}/finish. It always carries the full enabled list, the full ask-first list and the agent access, because the page rewrites the whole set on every toggle (apply). Open DevTools > Network, click Ask first, and read that request's status and error field. Two messages are worth knowing:

• 403 Board mutation requires trusted browser origin: the browser Origin doesn't match the Host Paperclip sees, which can happen behind a reverse proxy. Set PAPERCLIP_PUBLIC_URL to the exact URL you open (guard).
• 400 Disabled actions cannot be enabled: the stored profile still includes an action whose catalog status is disabled. The page hides it but resends its id on every save (check).

Workaround: set one action through the API. Run this in the browser console on the Paperclip tab, so your session cookie and Origin are used:

const connectionId = location.pathname.match(/\/apps\/([0-9a-f-]{36})/)[1];
const { companyId } = await (await fetch(`/api/tool-connections/${connectionId}`)).json();
const { catalog } = await (await fetch(`/api/tool-connections/${connectionId}/catalog`)).json();
const action = catalog.find((e) => (e.title ?? e.toolName) === "Get Entity State");
console.log(action.id, action.status, action.isReadOnly); // expect "active", true

const res = await fetch(`/api/companies/${companyId}/tools/apps/${connectionId}/finish`, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    preserveExistingAccess: true,
    enabledCatalogEntryIds: [action.id],
    askFirstCatalogEntryIds: [action.id],
    access: { agentIds: [] },
  }),
});
console.log(res.status, await res.json());

preserveExistingAccess: true makes the server merge in the existing agent bindings, profile entries and ask-first policies instead of replacing them (merge, policies kept). So this adds exactly one action as Ask first and leaves the 8 writes Off. A few details:

• To make it Allowed instead, leave the id out of askFirstCatalogEntryIds. To add more reads, put more ids in both arrays.
• This mode only adds. To turn something Off later, use the UI or a full call without the flag (that replaces the set and the agent access with what you send).
• Check profileBindings in the response. If it's empty, no agent can use the connection yet. Rerun with the agent ids in access.agentIds.

Auth and validation for that route (route, schema):

• It needs a signed-in board user with an active, non-viewer membership. On top of that, you must be instance admin, hold tools:manage_connections, or be the connection's creator. That's the same rule behind canConfigure, so you pass (check).
• Ids must be UUIDs, and access is required.
• The service rejects ids from another connection, disabled actions, and archived connections.

If this call also fails, its error text is what is blocking the UI.

I found no existing issue, PR or discussion for this. PermissionsPanel.tsx hasn't changed since #15216 (2026-10-05), so no release and nothing on master changes this control. Release tags also lag master: v2026.1106.0 is built from master as of 2026-10-23.