[Windows][Sites] Deployment blocked by sandbox_approval policy despite “Ask for approval” being selected #50841

What version of the Codex App are you using (From “About Codex” dialog)?

26.930.21537

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Windows; PowerShell / Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

I cannot publish a website through the Sites plugin in the Windows desktop app.

The official site-workflow.mjs helper starts successfully and waits for workflow JSON on stdin. However, the subsequent write_stdin call is rejected with this exact error:

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

The approval option in the UI is set to “Ask for approval,” and I have explicitly authorized deployment multiple times. Nevertheless, no actionable approval prompt appears.

Site project creation, project retrieval, and temporary credential issuance succeed. The workflow fails when passing the credential and workflow JSON to the running helper, before source upload or publication.

For newly created test projects, the reported state remains version 0 with current_live_url: null.

This has blocked attempts to update an existing website, publish a new version as a separate website, and publish an independent minimal static HTML test site.

What steps can reproduce the bug?

The following sequence reproduces the issue in my current environment:

1. Open the Windows desktop app with the Sites plugin installed.

2. Select “Ask for approval” in the approval settings.

3. Ask the agent to create and publish a minimal static HTML website, and explicitly authorize publication.

4. Let the agent create or retrieve the Site project and request the temporary Sites credential. These operations succeed.

5. Start the official helper through exec_command with a PTY:

   node /scripts/site-workflow.mjs --project-id

6. The helper starts and prints:

   Ready for Site workflow JSON on stdin (input is hidden).

7. Following the plugin workflow, the agent calls write_stdin for the running session, supplying JSON containing:

   • credential: the temporary Sites credential
   • commands: []
   • archivePath: the local archive path

   The JSON is followed by a newline. The credential is passed through stdin, not included in command-line arguments.

8. The write_stdin call is rejected:

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

9. No approval prompt appears, and the workflow cannot proceed to source upload or publication.

Retrying after explicitly granting network access through request_permissions produces the same error.

The same failure was observed with Sites plugin versions 0.1.75 and 1.0.0-b.

Session ID: not available for this report.
Token limit usage and context window usage: not recorded.

What is the expected behavior?

The official Sites deployment workflow should proceed when the necessary permissions are available, or present an actionable approval prompt when additional authorization is required.

If deployment is unsupported under the current configuration, the app should clearly identify the restriction and provide a supported way to resolve it.

Currently, the UI is set to “Ask for approval,” but the operation is rejected because sandbox_approval is false, without giving me an approval prompt or a usable next step.

I am not requesting a bypass of security controls. I am requesting a working authorization path for the supported Sites deployment workflow.

Additional information

Effective approval configuration reported to the agent:

{
"granular": {
"sandbox_approval": false,
"rules": false,
"skill_approval": false,
"request_permissions": true,
"mcp_elicitations": true
}
}

Sandbox mode: workspace-write.

Checks already performed:

• Network access was explicitly granted through request_permissions during a retry, but the error persisted.
• The issue also occurs with an independent minimal static HTML site that does not require authentication, a database, photo uploads, or user data.
• The larger application passed its local build and 12 automated tests.
• A separate Node stdin diagnostic succeeded: write_stdin sent “diagnostic\n”, the process printed “Input received”, and it exited with code 0. This indicates that write_stdin is not universally broken.
• The observed failure occurs specifically during the Sites workflow credential handoff. The exact condition triggering the approval requirement is unknown.
• An earlier version of my website was successfully deployed through a different helper path. This does not establish a regression in the same workflow.

Please investigate why this operation requires an approval category that is disabled in the effective policy, and how that policy relates to the “Ask for approval” option shown in the UI.

Credentials, project identifiers, and personal filesystem paths have been omitted.