Sandboxed command execution hangs without output for simple commands

Resolved 💬 1 comment Opened May 2, 2026 by hipotures Closed May 2, 2026

What version of Codex CLI is running?

codex-cli 0.128.0

What subscription do you have?

Pro Lite

Which model were you using?

GPT-5.5 high

What platform is your computer?

6.18.18-1-MANJARO x86_64 unknown

What terminal emulator and version are you using (if applicable)?

WarpTerminal v0.2026.04.27.15.32.stable_03 dumb /usr/bin/zsh

What issue are you seeing?

Commands executed in the sandboxed environment sometimes hang indefinitely without producing any stdout or stderr. This affects even simple commands that should complete immediately, such as pwd, sed, and
git status.

Observed behavior:

  • git status --short --branch produced no output and appeared to hang.
  • sed -n ... also produced no output.
  • pwd did not return promptly either.
  • Running the equivalent Git command outside the sandbox completed immediately and returned the expected status.

Expected behavior:
Simple commands should either complete normally and return output, or fail with a clear error message. They should not hang silently.

Impact:
This makes debugging difficult because it is unclear whether the command is blocked by the project, Git, the shell, the sandbox, or the PTY/output layer. It can also lead to unnecessary retries or escalation
outside the sandbox.

Evidence:
In the affected repository, git status --short --branch hung in the sandbox. When rerun outside the sandbox, it immediately returned:

## main...origin/main
D " "
?? .codex/

Likely area:
Sandboxed command execution, PTY handling, stdout/stderr buffering, or filesystem access mediation.

Suggested investigation:

  • Check whether sandboxed commands are blocked before process startup or during output collection.
  • Verify whether stdout/stderr is being buffered or not flushed back to the caller.
  • Compare behavior between sandboxed and non-sandboxed execution for short-lived commands.
  • Add timeout diagnostics that report whether the process started, whether output was captured, and where execution is blocked.

thread ID 019de9ca-8125-7013-b67f-bedd6a28f230

What steps can reproduce the bug?

Uploaded thread: 019de9ca-8125-7013-b67f-bedd6a28f230

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗