Repository navigation
Desktop app blocks write_stdin with sandbox_approval=false despite “Ask for approval” being selected #52210
Description
What version of the Codex App are you using (From “About Codex” dialog)?
ChatGPT Desktop 26.1002.52244 (build 13536), macOS
What subscription do you have?
ChatGPT Pro
What platform is your computer?
MacOS
What issue are you seeing?
Title: Desktop app blocks write_stdin with sandbox_approval=false despite “Ask for approval” being selected
Problem
In the ChatGPT desktop app on macOS, a website publishing workflow is blocked when the assistant uses write_stdin to send input to a running process.
The permissions selector shows “Ask for approval”, but no approval prompt appears. The tool immediately returns:
write_stdin rejected: approval required by policy, but AskForApproval::Granular.sandbox_approval is false
Steps to reproduce
- Select “Ask for approval” in the desktop app.
- Ask the assistant to update and publish an existing Sites application.
- The assistant starts the publishing helper using
exec_commandwith a terminal session. - The process reports that it is ready to receive input.
- The assistant sends the required input through
write_stdin. - The tool rejects the action with the error above.
Expected behavior
If the action requires approval, the app should display an approval prompt, or clearly explain which policy prevents approval.
Actual behavior
The action is rejected automatically, despite the selected permission mode. Publication cannot proceed.
Checks already performed
- Restarted and updated the desktop app; the issue persisted in the latest retry on October 7, 2026.
- Explicitly granted network access through
request_permissions; the grant succeeded, butwrite_stdinstill failed. - Earlier checks found no
approval_policysetting in the user or examined project configuration files. - No
/etc/codex/config.toml,/etc/codex/requirements.toml, or/etc/codex/managed_config.tomlwas found. - macOS reported no DEP or MDM enrollment.
- Commands started through
exec_commandworked. In the tested sessions, polling with emptywrite_stdininput worked, while non-empty input was rejected.
Relevant log evidence
Before the latest app update, a desktop log entry showed both requestApprovalPolicy and resolvedApprovalPolicy with:
{"granular":{"sandbox_approval":false,"rules":false,"skill_approval":false,"request_permissions":true,"mcp_elicitations":true}}
The same entry included:
requestApprovalsReviewer=user
resolvedApprovalsReviewer=user
requestPermissionProfile=:workspace
useAppServerPermissionDefault=false
We have not identified which layer supplies this policy.
Environment
- macOS, ChatGPT desktop app.
- Before the latest update: ChatGPT 26.930.21537, build 12776.
- Bundled CLI at that time:
codex-cli 0.159.0-alpha.12.1. - The current post-update version has not yet been collected.
Impact
Updates to an existing application cannot be published. The last published version remains available.
The issue has also been escalated through the Help Center. Please advise how to identify the source of the effective policy and resolve the mismatch with the selected approval mode without disabling security protections.
Activity
github-actions commentedon Oct 8, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Brunomonk commentedon Oct 8, 2026
I think I deleted the duplicate. Please confirm.
Jonson-lab commentedon Oct 13, 2026
I am also encountering this issue on macOS during a Sites publishing workflow.
The desktop app's permissions selector shows “Ask for approval”, but sending input to the publishing helper through
write_stdinis rejected with:No approval prompt appears, and completed website changes cannot be published. Explicit network permission was granted, but this did not resolve the
write_stdinrejection. The source of the effective approval policy has not been identified.Related report: #53064
Please investigate whether the selected approval mode is consistent with the effective execution policy, and advise how to resolve this without disabling security protections.
For privacy, this comment omits feedback/session IDs, website URLs, customer/product data, and conversation logs.
dby94w85fm-lgtm commentedon Oct 14, 2026
Additional Windows reproduction: harmless PTY stdin works before a network permission grant, but is rejected after the grant.
Environment:
Minimal reproduction without credentials or external requests:
No actionable approval prompt appeared. This blocks the supported Sites publishing helper, but the reproduction above is independent of Sites, credentials, uploads, or a remote endpoint.
Read-only checks found no explicit approval_policy override in the examined user/project configuration and no requirements.toml or managed_config.toml in the usual Windows system location. This does not rule out cloud-managed policy. The saved thread policy showed sandbox_approval=false and request_permissions=true. No security settings, app state, or session databases were modified.
Please investigate permission-grant propagation and approval classification for non-empty write_stdin after scoped network permission is granted. The exact internal cause has not been established.
This report intentionally excludes account information, local paths, private project identifiers, API keys, session IDs, and conversation logs.