Codex keeps prompting for approval + excessive `cd` prepended shell commands

Resolved 💬 6 comments Opened Nov 27, 2025 by segersniels Closed Nov 28, 2025

What version of Codex is running?

codex-cli 0.64.0-alpha.9

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.1-codex-max

What platform is your computer?

Darwin 25.0.0 arm64 arm

What issue are you seeing?

Codex keeps prompting for excessive permission approval because every command is prefixed with cd $(pwd)/... &&.

After asking why it kept doing that it mentioned that it got confused by the tool description and misinterpreted it that it needed to add the working directory to the shell command. Even though it is explicitly instructed to not do that: https://github.com/openai/codex/blob/cbd7d0d54330443887852b21636c816f60f1bde8/codex-rs/core/src/tools/spec.rs#L1981

After adding a section dedicated to tool execution behavior in my AGENTS.md it kind of improved its behavior But this is far from ideal:

## Tool execution behavior

Evaluate these statements against your internal tool schemas and see if they are still valid. If not, let the user know and ask for confirmation before proceeding.

- Shell tool behavior: The `shell_command` tool already accepts a `workdir` parameter to set the working directory. Do NOT embed `cd … &&` inside the command string. Always pass the target path via `workdir`. Using `cd` inside the command bypasses the tool’s sandbox detection and triggers needless permission prompts. Treat any in-command `cd` as a violation.
- The CLI wrappers inspect workdir to decide sandbox scope. A `cd` inside the command looks like an attempt to escape the sandbox, so it asks for approval.
- Repeated `cd` wrappers cause `need permission outside workspace` dialogs on every run.
- Using only `workdir` keeps commands scoped correctly and avoids escalations.

With this instruction it stops doing it, but because it keeps passing in the workdir I assume that it also breaks the sandbox guards and keeps asking for permission? Like simple ripgrep commands or npm commands all spam for permissions each session.

So not sure how to proceed with this one except to raise attention to it. It eventually forces me to just give it full approvals so I don't have to deal with the permission spam when using workspace_write.

What steps can reproduce the bug?

Pretty much any codex session will start doing it. Don't think I've seen a session where it didn't do it.

What is the expected behavior?

Should not break sandbox permission guards when using commands within the current working directory.

Additional information

_No response_

View original on GitHub ↗

This issue has 6 comments on GitHub. Read the full discussion on GitHub ↗