Skip to content

Desktop app blocks write_stdin with sandbox_approval=false despite “Ask for approval” being selected #52210

Open

Description

@Brunomonk

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

  1. Select “Ask for approval” in the desktop app.
  2. Ask the assistant to update and publish an existing Sites application.
  3. The assistant starts the publishing helper using exec_command with a terminal session.
  4. The process reports that it is ready to receive input.
  5. The assistant sends the required input through write_stdin.
  6. 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, but write_stdin still failed.
  • Earlier checks found no approval_policy setting in the user or examined project configuration files.
  • No /etc/codex/config.toml, /etc/codex/requirements.toml, or /etc/codex/managed_config.toml was found.
  • macOS reported no DEP or MDM enrollment.
  • Commands started through exec_command worked. In the tested sessions, polling with empty write_stdin input 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

  1. added
    appIssues related to the Codex desktop app
    on Oct 8, 2026
  2. added
    bugSomething isn't working
    sandboxIssues related to permissions or sandboxing
    tool-callsIssues related to tool calling
    on Oct 8, 2026
  3. Brunomonk commented on Oct 8, 2026

    @Brunomonk
    Author

    I think I deleted the duplicate. Please confirm.

  4. Jonson-lab commented on Oct 13, 2026

    @Jonson-lab

    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_stdin is rejected with:

    write_stdin rejected: approval required by policy, but AskForApproval::Granular.sandbox_approval is false
    

    No approval prompt appears, and completed website changes cannot be published. Explicit network permission was granted, but this did not resolve the write_stdin rejection. 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.

  5. dby94w85fm-lgtm commented on Oct 14, 2026

    @dby94w85fm-lgtm

    Additional Windows reproduction: harmless PTY stdin works before a network permission grant, but is rejected after the grant.

    Environment:

    • Windows desktop app 26.1007.71326, build 20398, prod channel (in-app update checker, 2026-10-14: up_to_date).
    • Permissions UI shows "Ask for approval".
    • Node.js 24.x, PowerShell PTY.
    • Restarting and reinstalling did not resolve the observed behavior.

    Minimal reproduction without credentials or external requests:

    1. Save permission-ping.cjs:
    const rl = require('node:readline').createInterface({
      input: process.stdin, output: process.stdout
    });
    console.log('READY');
    rl.once('line', s => {
      console.log(s === 'ping' ? 'PING_OK' : 'INPUT_RECEIVED');
      rl.close();
    });
    1. Start it with exec_command, tty=true.
    2. Before requesting additional network permission, write_stdin with chars="ping\r\n" returned PING_OK in the diagnostic run.
    3. Request network permission with request_permissions, network.enabled=true. A grant was returned (session and turn scopes have both been observed).
    4. Start a fresh instance of the same program.
    5. Send exactly the same harmless input using write_stdin. It is rejected before reaching the process:
    write_stdin rejected: approval required by policy, but AskForApproval::Granular.sandbox_approval is false
    

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxingtool-callsIssues related to tool calling

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions