The pattern, seen on two unrelated surfaces
Plugin trust. Clicking Review on the computer-use install prompt renders a full review card and ends with:
/plugin trust computer-use d4148707e384b2cec9da273dfc3fa162186772046a26cc0ef11d4fd86218314f.d13ae6b9c51c8d3ab04b55e9c976539c35b5e407d3e7ad9bf3276e56d7343a32
A 129-character command the user is expected to type back. Founder's reaction: "that doesn't really do anything for us…?"
Automations delete. The detail pane prints:
run:/automations delete 0342181c-d8a2-4bcb-99b1-a286421a56a6 --confirm 7a06d6188f85eda9c4d554731a3dd86274ae6218a0985eb25fdefc1237a8bacd
Same shape. The founder reported it simply as "the delete thing doesn't work here in automations" — which is the correct reading from the outside: an action that emits an instruction has not acted.
Two independent surfaces, one interaction defect: a confirmed action renders its own command instead of performing it.
Why the token itself is not the problem
The pinning is sound and should stay. Plugin trust binds to an exact content hash + capability hash — d4148707… / d13ae6b9… — so approval cannot drift to different content. The automations token is the same idea for a destructive delete. Neither should be dropped.
The defect is where the token lives. It belongs to the confirm control, not to the user's keyboard. A human retyping a 64-hex digest adds no security — nobody verifies it by eye — while costing every user the action.
Suggested shape
The review/detail view already computed the token, so it can carry it: a confirm affordance that submits the exact same command with the exact same hash, plus a visible copy path for anyone who wants the literal command. AGENTS.md's "an abstraction must delete caller code" applies to interaction too — a button that prints a command has not replaced the command.
Keep the reviewed-content binding, the recheck at dispatch/spawn/use, and the trust-vs-enable distinction the card states ("trust stages the exact reviewed content but does not activate it"). Only the retype goes away.
Adjacent finding, worth its own look
The computer-use builtin is State: disabled, Trust: not-reviewed, Active components: [none] — bundled and snapshot-staged but never activated. Meanwhile the same machine runs computer use through CuaDriver.app (cua-driver mcp, cua-driver serve) registered as an ordinary MCP server. So the product ships two routes to one capability, and the prompt offers a third. Whether the builtin should be offered at all when an equivalent MCP server is already connected is a real question — it is also why this install prompt kept appearing for something the user already had.
Related: the plugin-suggestion prompt cannot be permanently dismissed and matched on the keyword mcp (GitHub #6031).
The pattern, seen on two unrelated surfaces
Plugin trust. Clicking Review on the computer-use install prompt renders a full review card and ends with:
A 129-character command the user is expected to type back. Founder's reaction: "that doesn't really do anything for us…?"
Automations delete. The detail pane prints:
Same shape. The founder reported it simply as "the delete thing doesn't work here in automations" — which is the correct reading from the outside: an action that emits an instruction has not acted.
Two independent surfaces, one interaction defect: a confirmed action renders its own command instead of performing it.
Why the token itself is not the problem
The pinning is sound and should stay. Plugin trust binds to an exact content hash + capability hash —
d4148707…/d13ae6b9…— so approval cannot drift to different content. The automations token is the same idea for a destructive delete. Neither should be dropped.The defect is where the token lives. It belongs to the confirm control, not to the user's keyboard. A human retyping a 64-hex digest adds no security — nobody verifies it by eye — while costing every user the action.
Suggested shape
The review/detail view already computed the token, so it can carry it: a confirm affordance that submits the exact same command with the exact same hash, plus a visible copy path for anyone who wants the literal command.
AGENTS.md's "an abstraction must delete caller code" applies to interaction too — a button that prints a command has not replaced the command.Keep the reviewed-content binding, the recheck at dispatch/spawn/use, and the trust-vs-enable distinction the card states ("trust stages the exact reviewed content but does not activate it"). Only the retype goes away.
Adjacent finding, worth its own look
The computer-use builtin is
State: disabled,Trust: not-reviewed,Active components: [none]— bundled and snapshot-staged but never activated. Meanwhile the same machine runs computer use throughCuaDriver.app(cua-driver mcp,cua-driver serve) registered as an ordinary MCP server. So the product ships two routes to one capability, and the prompt offers a third. Whether the builtin should be offered at all when an equivalent MCP server is already connected is a real question — it is also why this install prompt kept appearing for something the user already had.Related: the plugin-suggestion prompt cannot be permanently dismissed and matched on the keyword
mcp(GitHub #6031).