Computer Use approval bridge drops persistence choices and response metadata, causing repeated prompts

[austinm911]

Computer Use repeatedly asks to approve the same app through Executor. The approval bridge drops the offered persistence choices and the response metadata needed to select session persistence.

Environment: macOS, Executor desktop/CLI 1.6.8, Codex app-server 0.153.4, installed Sky 0.6.26. Source inspection was against 2dc399e51094fccd2a45103a38d77179c6d648ff.

Observed behavior

Using Executor's Computer Use integration to read, type into, and click in Google Chrome required another approval for each operation, including repeated operations within one execution. Immediately accepting approvals allowed the operations to succeed.

Expected: when the runtime offers session persistence, the host should be able to select it and subsequent operations against the approved app should honor that selection for the session.

Independent runtime verification

To isolate this from Executor's execution and pooling behavior, I exercised the installed codex app-server directly over JSON-RPC. I created one ephemeral thread and made four mcpServer/tool/call requests to node_repl/js, keeping threadId and metadata session_id fixed while assigning a fresh metadata turn_id for each call, matching Executor's adapter behavior.

Each call ran:

globalThis.sky ??= (await import('@oai/sky')).sky;
await sky.get_app_state({ app: 'Google Chrome', disableDiff: true });
nodeRepl.write('read completed');

For the first two calls, the response to mcpServer/elicitation/request was:

{"action":"accept","content":{}}

For the third call, it was:

{"action":"accept","content":{},"_meta":{"persist":"session"}}

Call	Approval response	Prompts	Tool error
1	Accept without metadata	1	false
2	Accept without metadata	1	false
3	Accept with session persistence	1	false
4	No prompt to answer	0	false

The runtime offered persist: ["session", "always"]. Only session persistence was selected. This demonstrates that response metadata is sufficient to suppress the next prompt in the same runtime session, even with a new turn ID. It does not depend on interpreting Sky's telemetry as its persistence implementation.

Source findings

An independent read-only source review confirmed the following losses:

• invoke.ts:132–144: approvalTerms recognizes persist, but only retains string values. The runtime's array of allowed persistence scopes is discarded. An isolated test of the extracted function confirmed this.
• elicitation.ts:44–48: ElicitationResponse has no response metadata field.
• invoke.ts:168–175: the outgoing response is rebuilt with only action and content.
• appserver-connector.ts: response decoding and serialization also preserve only action and content.
• tool-server.ts:455–458: the MCP host likewise drops response metadata from its client.

Suggested scope: support the recognized persistence-array contract, expose the offered selection to the approving user, and carry the selected response metadata through the host, core, plugin, and app-server adapters. This need not allow arbitrary request metadata or automatically grant persistent access. Regression coverage should include both the offered scopes and the selected response scope.

Related but separate: #1953 and #1956 concern elicitation waiting consuming the tool timeout. This reproduction accepts immediately and all four calls succeed, so the repeated prompt does not require a timeout.