What version of the Codex App are you using?
ChatGPT desktop app (retained bundle identifier com.openai.codex): 26.1002.52244, build 13536.
What subscription do you have?
Not captured during diagnosis. The affected flow is a ChatGPT Work/dot task connected to a local Mac through the desktop app.
What platform is your computer?
macOS 26.6.2 (25G83).
What issue are you seeing?
Computer Use permission prompts repeatedly return after the user selects Always allow. Desktop logs confirm the selection is sent as an MCP elicitation response with action: accept and _meta.persist: always, but the connected-runtime response path fails afterward.
Across the inspected desktop logs, 19 such responses were followed within the next few log entries by:
[electron-message-handler] Sending server response
method=mcpServer/elicitation/request
response={"action":"accept","content":{},"_meta":{"persist":"always"}}
[AppServerConnection] Unrecognized MCP message
hasError=true id=undefined kind=response
Many attempts then logged an abnormal connected-runtime WebSocket closure:
[AppServerConnection] app_server_connection.closed
code=1006 failureReason=unknown hostKind=durable signal=null transport=websocket
In one desktop run, the same elicitation request ID received 10 repeated persist: always replies. Another received 2. These were 12 responses, all followed by the unrecognized error; 10 also had a nearby abnormal durable connection closure. Request identifiers are omitted for privacy.
Nearby logs also repeatedly show:
error={"code":-32601,"message":"unsupported app-server method: mcpServerStatus/list"}
method=mcpServerStatus/list
This suggests an approval-routing/protocol compatibility failure, but the exact backend cause is unproven.
What steps can reproduce the bug?
Observed sequence, rather than a newly isolated reproduction:
- Use a ChatGPT Work/dot task with a connected Mac.
- Encounter a Computer Use permission prompt offering Always allow.
- Select Always allow.
- The app sends
accept / persist: always, receives the unrecognized error response, and the same request remains or returns.
- Selecting Always allow again repeats the response/error sequence.
A clean reproduction against a supported target application has not yet been isolated. One investigated task tried to inspect ChatGPT itself, which is documented as excluded from Computer Use; that attempt should not be treated as a supported target-app reproduction. The confirmed report is about the approval response/error loop and failure to settle the request correctly.
What is the expected behavior?
An accepted persistent app approval should settle the request and allow future authorized access to that app without repeating the same permission prompt. If the target is unsupported or persistence is unavailable, the UI should return a clear error and settle the request instead of repeatedly offering a nonfunctional approval.
Additional information
- Local approval persistence is not completely broken: a separate local elicitation response did not show the same error, and the local persistent approval store contains Calculator, Finder and System Events.
- The Node REPL executable is supplied by the installed app bundle. Its presence alone is not evidence of a user-added or rogue MCP server.
- Separate Computer Use calls ended with
node_repl kernel exited unexpectedly and kernel_status: exited(signal=9). No causal relationship between those exits and this permission-routing loop has been established.
- No configuration or permission changes were made during this diagnosis.
- This report contains only sanitized technical excerpts. It excludes raw logs, local usernames/paths, endpoint URLs, credentials, conversation contents and session identifiers.
What version of the Codex App are you using?
ChatGPT desktop app (retained bundle identifier
com.openai.codex): 26.1002.52244, build 13536.What subscription do you have?
Not captured during diagnosis. The affected flow is a ChatGPT Work/dot task connected to a local Mac through the desktop app.
What platform is your computer?
macOS 26.6.2 (25G83).
What issue are you seeing?
Computer Use permission prompts repeatedly return after the user selects Always allow. Desktop logs confirm the selection is sent as an MCP elicitation response with
action: acceptand_meta.persist: always, but the connected-runtime response path fails afterward.Across the inspected desktop logs, 19 such responses were followed within the next few log entries by:
Many attempts then logged an abnormal connected-runtime WebSocket closure:
In one desktop run, the same elicitation request ID received 10 repeated
persist: alwaysreplies. Another received 2. These were 12 responses, all followed by the unrecognized error; 10 also had a nearby abnormal durable connection closure. Request identifiers are omitted for privacy.Nearby logs also repeatedly show:
This suggests an approval-routing/protocol compatibility failure, but the exact backend cause is unproven.
What steps can reproduce the bug?
Observed sequence, rather than a newly isolated reproduction:
accept/persist: always, receives the unrecognized error response, and the same request remains or returns.A clean reproduction against a supported target application has not yet been isolated. One investigated task tried to inspect ChatGPT itself, which is documented as excluded from Computer Use; that attempt should not be treated as a supported target-app reproduction. The confirmed report is about the approval response/error loop and failure to settle the request correctly.
What is the expected behavior?
An accepted persistent app approval should settle the request and allow future authorized access to that app without repeating the same permission prompt. If the target is unsupported or persistence is unavailable, the UI should return a clear error and settle the request instead of repeatedly offering a nonfunctional approval.
Additional information
node_repl kernel exited unexpectedlyandkernel_status: exited(signal=9). No causal relationship between those exits and this permission-routing loop has been established.