fix(ce-work-beta): add explicit sandbox and approval flags to Codex delegation#363
fix(ce-work-beta): add explicit sandbox and approval flags to Codex delegation#363mvanhorn wants to merge 2 commits intoEveryInc:mainfrom
Conversation
…elegation The delegate step told the agent to "run the delegate CLI" without specifying sandbox mode or approval policy. Users without global yolo config in ~/.codex/config.toml hit the network sandbox wall when Codex tried to install dependencies in non-interactive exec mode. Now specifies -s workspace-write (network + workspace disk access) and -a never (no approval prompts in non-interactive mode). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 857f3d9efa
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| 3. **Write prompt to file** — Save the assembled prompt to a unique temporary file to avoid shell quoting issues and cross-task races. Use a unique filename per task. | ||
|
|
||
| 4. **Delegate** — Run the delegate CLI, piping the prompt file via stdin (not argv expansion, which hits `ARG_MAX` on large prompts). Omit the model flag to use the delegate's default model, which stays current without manual updates. | ||
| 4. **Delegate** — Run the delegate CLI with `-s workspace-write -a never`, piping the prompt file via stdin (not argv expansion, which hits `ARG_MAX` on large prompts). The `-s workspace-write` flag grants workspace disk writes and network access (needed for `npm install`, `pip install`, dependency fetches). The `-a never` flag disables approval prompts, which is required because `exec` mode is non-interactive and has no user to prompt. Without these flags, users whose global Codex config does not set `approval_policy` and `sandbox_mode` will see delegation fail on any network operation. Omit the model flag to use the delegate's default model, which stays current without manual updates. |
There was a problem hiding this comment.
workspace-write does not automatically permit outbound network access, so this new instruction still leaves delegation unable to run networked steps like npm install/pip install for users without prior config. The same upstream Codex config surface separates sandbox mode from sandbox_workspace_write.network_access, and the protocol default for workspace-write sets network_access: false; as written, this step claims network is granted and will continue to fail in exactly the dependency-fetch scenarios it is trying to fix.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in fa01f03 - switched from workspace-write to danger-full-access to guarantee network access for dependency fetches regardless of user config.
…gation The delegate step told the agent to run Codex without specifying sandbox or approval flags. Users without permissive global Codex config saw delegation fail on the first network operation (e.g., npm install). PR EveryInc#363 proposed hardcoding `-s workspace-write -a never`, but one-shotting via `codex exec` likely needs `--yolo` for non-trivial tasks since workspace-write still restricts system-level access. Add a new step 2 to the External Delegation Workflow that presents three security posture options: - Default (no flags) -- uses Codex defaults, will likely fail in exec mode - Workspace write (--full-auto) -- moderate access, may still fail - Full access (--yolo) -- disables all restrictions, with explicit risk warnings about data deletion, secret leakage, and unapproved commands The choice is asked once per delegation session and applied to all delegated tasks. Uses cross-platform question tool with numbered-list fallback per the skill checklist. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…egation workspace-write does not guarantee outbound network access across all Codex versions and configurations. Delegation tasks often need npm install, pip install, or other dependency fetches. Switch to danger-full-access to ensure network operations succeed regardless of the user's Codex config. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1 participant
Summary
The ce-work-beta delegate step tells the agent to "run the delegate CLI" without specifying sandbox mode or approval policy flags for
codex exec. This causes delegation to silently fail for users who don't have global yolo config in~/.codex/config.toml.Why this matters
Codex CLI defaults to a restrictive sandbox that blocks network access and an approval policy that prompts the user. In
exec(non-interactive) mode, there's no user to prompt, so Codex gives up on any operation that needs approval - likenpm installorpip install.Users who have
approval_policy = "never"andsandbox_mode = "danger-full-access"in their global~/.codex/config.tomlnever see this because their config overrides the defaults. But anyone with default Codex settings sees delegation fail on the first network operation, triggering the fallback to standard mode every time.I hit this exact pattern while fixing Codex delegation in another project. A contributor reported that delegation always failed and fell back. Root cause was identical: missing
-sand-aflags on thecodex execinvocation.Changes
Added
-s workspace-write -a neverto step 4 ("Delegate") inskills/ce-work-beta/SKILL.md:-s workspace-write- grants workspace disk writes + network access-a never- disables approval prompts (required for non-interactive exec mode)workspace-writeis the least-privilege option that still allows what delegation needs. It's notdanger-full-access- Codex can only write within the workspace directory.This contribution was developed with AI assistance (Claude Code).