Repository navigation
macOS desktop: Sites source sync blocked by granular sandbox approval after scoped network grant #53601
Description
Environment
- macOS desktop application installed as ChatGPT.app
- Bundle identifier: com.openai.codex
- Version: 26.1007.30912 (20156)
- Dates observed: October 12–13, 2026 (Europe/Rome)
- Whether the workspace/device is managed: not yet confirmed
Problem
The General settings screen shows Full access enabled, but a task using the official Sites source workflow cannot complete. This UI state does not establish which permission mode is selected for the active task.
The helper starts and prints Ready for Site workflow JSON on stdin (input is hidden). Sending its request through write_stdin is rejected with:
write_stdin rejected: approval required by policy, but AskForApproval::Granular.sandbox_approval is false
There is no actionable approval prompt.
Reproduction observed
- Start the official Sites source workflow helper in an existing local project.
- Send the workflow request through its hidden stdin, keeping credentials in memory.
- Observe the rejection above.
- Fully quit and restart the desktop app.
- On one retry, stdin succeeds, but Git reports DNS failure for the Sites source host.
- Approve a scoped network permission request; the returned permission is network.enabled=true for the turn.
- Restart the same helper and send the request again.
- The same granular approval rejection occurs.
Checks already completed
- User configuration was parsed: no approval_policy, sandbox_mode, sandbox_approval, or request_permissions fields were found, including nested fields.
- No project .codex/config.toml was found in the project and relevant parent directories checked.
- Scoped network and project Git-directory permission grants did not resolve the issue.
- Local application build succeeds; Sites publication has not completed.
- Runtime instructions report granular sandbox_approval=false and request_permissions=true.
Expected
The supported Sites source workflow should either operate within the granted permissions or present an actionable explanation/approval path. Please clarify how the active task policy is selected and whether stdin continuation is incorrectly gated after a scoped grant.
No credentials, email addresses, local usernames, project identifiers, or session transcripts are included in this report.
Activity
github-actions commentedon Oct 13, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
goranvukck-web commentedon Oct 13, 2026
I am also affected on macOS, with a credential-free reproduction in addition to the Sites helper failure.
Environment
uname -mprs:Darwin 27.0.0 arm64 armup_to_date; restarting the app and reopening the conversation did not resolve it.Observed sequence on 13 October 2026
write_stdinwithtest\nsucceeded in a harmless interactive Node process.request_permissionswithpermissions.network.enabled: truewas approved (scope: turn,strict_auto_review: true).exec_command(tty: true,yield_time_ms: 1000):node -e 'process.stdin.setEncoding("utf8"); process.stdin.once("data", () => { console.log("Input received"); process.exit(0); }); setTimeout(() => process.exit(2), 20000); console.log("Ready for stdin");'test\nusingwrite_stdinto the returned session ID. The call is rejected before execution:The test uses no credentials, network calls or repository access. Empty polling (
chars: "") still works. The effective conversation policy reportssandbox_approval: falseandrequest_permissions: true. This is the observed sequence, not a confirmed root-cause diagnosis.The official Sites helper likewise starts and waits for hidden stdin, but cannot receive its input. No source update was published. Please investigate a supported approval path; no safeguards were disabled and no credentials were moved into files or command-line arguments.
Feedback IDs (not confirmed conversation/session IDs):
goranvukck-web commentedon Oct 14, 2026
Retested on 14 October 2026 in the same macOS desktop conversation: the issue still reproduces.
Before requesting additional network access, a credential-free stdin test succeeded. The official Sites helper also accepted its request through hidden stdin, but Git failed with
Could not resolve host: git.chatgpt-team.site.After
request_permissionsgrantednetwork.enabled=true(scope: turn,strict_auto_review: true), a fresh helper started, butwrite_stdinwas rejected before execution:This is the observed sequence, not a confirmed root cause. No source was retrieved or new version published. No credentials were put in files or command-line arguments, and no security settings were changed.
Could you provide a supported way to continue the official Sites workflow after the scoped network grant, or identify the policy layer rejecting stdin without an actionable approval prompt?