›_ Codex Issues
Codex Issues / #7852

--full-auto and --sandbox workspace-write flags cause indefinite hang with orphaned child processes

Open 💬 5 comments Opened Dec 11, 2025 by ghul0
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

codex-cli 0.66.0

What subscription do you have?

PRO

Which model were you using?

gpt-5.1-codex-max

What platform is your computer?

Linux 6.8.0-87-generic x86_64

What issue are you seeing?

When using --full-auto or --sandbox workspace-write flags with codex exec, commands hang indefinitely even for simple operations that complete in milliseconds without these flags.

Test results:

| Command | Result | Time |
|---------|--------|------|
| codex exec "echo test" | ✅ Works | ~2s |
| codex exec --json "echo test" | ✅ Works | ~2s |
| codex exec --full-auto "echo test" | ❌ HANGS | >2min |
| codex exec --sandbox workspace-write "echo test" | ❌ HANGS | >2min |

Symptoms:

  • Command output shows successful completion in JSONL log
  • Codex never returns control to caller
  • Child processes remain orphaned in S (sleeping) state
  • exit_code: null, status: "in_progress" persists indefinitely

Note: This is separate from issue #7846 (process substitution). This bug occurs with the --full-auto/--sandbox flags themselves, even with simple commands like echo.

What steps can reproduce the bug?

Minimal reproduction:

```bash
# Step 1: This WORKS (no sandbox flags)
timeout 30s codex exec --dangerously-bypass-approvals-and-sandbox \
"Run: echo 'hello world'"
# Result: Completes in ~2-5 seconds

# Step 2: This HANGS (with --full-auto)
timeout 30s codex exec --dangerously-bypass-approvals-and-sandbox \
--full-auto "Run: echo 'hello world'"
# Result: Times out after 30s

# Step 3: This also HANGS (with --sandbox workspace-write)
timeout 30s codex exec --dangerously-bypass-approvals-and-sandbox \
--sandbox workspace-write "Run: echo 'hello world'"
# Result: Times out after 30s

# Step 4: Check for orphaned processes after timeout
pgrep -af 'codex|echo' | grep -v pgrep
```

### Full reproduction script:

```bash
#!/usr/bin/env bash
set -euo pipefail
echo "=== Test 1: Without --full-auto ==="
time timeout 20s codex exec --dangerously-bypass-approvals-and-sandbox \
"Run: echo test" 2>&1 | tail -3

echo "=== Test 2: With --full-auto (will hang) ==="
time timeout 20s codex exec --dangerously-bypass-approvals-and-sandbox \
--full-auto "Run: echo test" 2>&1 | tail -3
echo "Exit code: $?"
```

What is the expected behavior?

  • Commands with --full-auto should complete in similar time as without the flag (~2-5s for simple commands)
  • All child processes should be terminated when Codex exits
  • No orphaned processes should remain after command completion
  • exit_code should be set to actual return value (0 for success)

Additional information

Root cause analysis:

The issue appears to be in process group management when sandbox mode is active:

  1. Missing setpgid(0, 0) - Child processes not placed in own process group
  2. Signal propagation - Signals sent only to direct child PID, not entire group
  3. Grandchild orphaning - Sandbox intermediate processes create orphans
  4. Pipe deadlock - Codex waits for EOF on pipes kept open by orphans

### Related issues:

  • #7846 - Process substitution hang (different trigger, same root cause)
  • #4726 - Missing child.wait() (closed)
  • #3836 - Async process management

### Workaround:
Remove --full-auto flag. Use --json alone if JSON output needed.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 8 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #7846

Powered by Codex Action

sayan-oai contributor · 8 months ago

Hey @ghul0, thanks for reporting. Like #7846, I wasn't able to repro with Ubuntu 22, bash, and Codex v0.66.

In fact, I don't believe codex exec --dangerously-bypass-approvals-and-sandbox --full-auto "Run: echo 'hello world'" even runs; Codex errors if you try to run with both --dangerously-bypass-approvals-and-sandbox and --full-auto. Let me know if you're seeing otherwise.

Would you mind sharing the thread-id of a session where you see this issue? You can get the thread-id via the /feedback command in the CLI. Thanks.

ghul0 · 8 months ago

Isolated a minimal, single-function test that reliably reproduces this issue. The root cause appears to be asyncio.to_thread()
failing to complete in the exec --full-auto sandbox environment.

---
## Minimal Test Case
### Reproduction Steps

  1. Create test file:
 cat > /tmp/test_asyncio_hang.py << 'EOF'
 import asyncio

async def main():
    result = await asyncio.to_thread(lambda: 42)
    assert result == 42
    print("OK")

asyncio.run(main())
EOF
  1. Run with exec --full-auto (HANGS):

codex exec --full-auto "Run: python -m pytest /tmp/test_asyncio_hang.py -v"
Result: Hangs indefinitely, killed by timeout after 2min (set by codex on bash tool execution) (exit code 124)

  1. Run with exec only (WORKS):

codex exec "Run: python -m pytest /tmp/test_asyncio_hang.py -v"
Result: Completes in ~2s

  1. Run in interactive mode with --full-auto (WORKS):

codex --full-auto
Then type: Run: python -m pytest /tmp/test_asyncio_hang.py -v
Result: Completes in ~2s

---
Test Matrix

| Mode | --full-auto | Result | Time |
|---------------------|-------------|--------|-----------------|
| codex exec | ✓ | HANGS | >2min (timeout) |
| codex exec | ✗ | OK | ~2s |
| codex (interactive) | ✓ | OK | ~2s |
| codex (interactive) | ✗ | OK | ~2s |

---
Analysis

The issue is specific to the combination of exec subcommand + --full-auto flag.

asyncio.to_thread() internally uses concurrent.futures.ThreadPoolExecutor to spawn worker threads. In the exec --full-auto sandbox
environment, these threads appear to never complete — consistent with the process group and signal propagation issues described in
this thread.

Notably, the same --full-auto flag works correctly in interactive mode, suggesting the bug lies in how exec mode sets up or tears
down the sandbox process environment.

---
Environment

  • Codex CLI: v0.69.0
  • Python: 3.12.3
  • pytest-asyncio: 1.2.0
  • OS: Ubuntu Linux (6.8.0-87-generic)
etraut-openai contributor · 7 months ago

@ghul0, are you still able to repro this problem? If so, please use the /feedback slash command to upload your logs and post the thread ID here.

LouRohanNV · 21 days ago

```markdown
Yes, this is still reproducible. It also occurs in the current managed
workspace-write sandbox used by an interactive Codex agent session—not only
with codex exec --full-auto`.

Minimal reproduction:

timeout 5s python3 -c 'import asyncio; asyncio.run(asyncio.to_thread(print, "thread-ok"))'
echo $?

Inside the Codex sandbox:

thread-ok
124

The worker thread runs and prints its output, but Python never exits. timeout
eventually kills it.

The identical command run outside the sandbox completes immediately with exit
code 0:

thread-ok
0

Environment:

  • Linux 6.8.0-124-generic x86_64
  • Python 3.10.12
  • Installed @openai/codex package: 0.129.0
  • Sandbox implementation visible in the process tree: bwrap invoking

codex-linux-sandbox

  • Sandbox policy: managed workspace-write, with network restricted

This standard-library-only reproduction suggests the problem is in the
sandbox's handling of asyncio.to_thread() or thread-pool shutdown.

It also suggests that the issue persists and now affects an interactive
managed sandbox, rather than only the codex exec --full-auto case originally
reported.

Feedback/thread ID: 019fd77c-5c0c-7432-a147-cdc677d89098

````