[currentbits]

Codex app-server item/fileChange/requestApproval and item/permissions/requestApproval ServerRequests used to get a JSON-RPC error straight away. Now they go through the same pending-permission queue and PermissionPrompt card that command approvals already use (#1190). MCP elicitation and user-input requests are still recognized but unsupported, so they keep returning an error.

What changed

electron/codexApprovals.js

• classifyServerRequest has a new "approval" action. It covers file-change requests, and permission requests whose permissions is an object.
• New pendingFromApproval builds the pending card:
  • File change: the request itself carries no diff. The card shows the diff from the fileChange item that streamed in just before it, plus reason and grantRoot when present. If that streamed item can't be found, the function throws. The request then gets an error reply instead of a blind approval.
  • Sandbox permissions: the card shows cwd, reason and the requested profile. That profile is stored as grant, so Accept grants exactly what was asked for and nothing broader.
  • Both kinds offer Accept, Accept for session and Decline.
• approvalResponse now handles permission requests:
  • Accept returns the requested network/fileSystem entries with scope: "turn".
  • Accept for session returns the same entries with scope: "session".
  • Decline and cancel return an empty profile, which grants nothing.

electron/runner-permissions.js

• Requests classified as approval are accepted.
• For file changes, the runner finds the matching streamed tool message by itemId and passes its input in as the diff.
• When a decision is sent back, the stored pending.grant is passed as the reply content. The exception is input requests, which still use the validated input values.

Tests

• Unit tests check:
  • classification of both request kinds
  • that a sandbox profile is granted exactly for accept and session, and as nothing for decline and cancel
  • that a file-change card is never built without its diff
• New end-to-end tests send these through the real JSON-RPC transport using new ask-permissions and ask-file-change scenarios in fakeCodexCli:
  • permissions with allowAlways and with deny
  • file change with allow
  • stopping a run while a sandbox-permission ask is open grants nothing
• Existing test names were updated, since file-change requests no longer always return an error.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-15T15:32:42.608190Z	a14ae04	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a14ae04cba

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve the full file-change diff for approval

For any file-change payload whose serialized changes exceeds INPUT_TRUNCATE (2,000 characters), this reads tool.input, which was already truncated by ingestCodexTool in runner-provider-codex.js, and presents only that prefix in the approval card; accepting still authorizes the entire server-side patch, including every unseen hunk. Keep an untruncated ephemeral copy of the streamed changes for approval correlation rather than sourcing the security decision from the display-truncated message.

Useful? React with 👍 / 👎.