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

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

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

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 ↗

6 Comments

segersniels · 9 months ago

I guess I can also just configure a bunch of .codexpolicy policies to contain all common used commands. But it still feels like the amount of requested approvals is excessive and feels like something is not working correctly.

etraut-openai contributor · 9 months ago

Thanks for submitting the bug report. It's not clear from your description whether this is a sandbox / tool-calling issue in the codex harness or a model behavior in the LLM. If you still have the session around, could you please resume it, use the /feedback tool to upload the session, and post the thread ID here? That will help us diagnose.

segersniels · 9 months ago

I don't have an explicit thread in mind but I'll try to remove some of the guards I put in place myself to get a good thread going for you to debug. Also there are existing open issues where you can clearly see the command doing excessive cd prepending like here https://github.com/openai/codex/issues/6960 just to do a simple sed.

etraut-openai contributor · 9 months ago

The cd prepend is model behavior.

We'll share the feedback with the team responsible for training our codex models. If you see other model behavior that you'd like to report, please use the /feedback command. That will provide us with additional details including logs and conversation text.

segersniels · 9 months ago

Thanks @etraut-openai. Any way for me to track progress on the issue?

etraut-openai contributor · 9 months ago

There's not really anything for you to "track" here. This isn't like a bug in a traditional program where a line of code needs to be updated to implement a bug fix. This is a model behavior issue. Each time we train a new model, we try to improve it based on user feedback.

Codex works with multiple models and reasoning levels. If you don't like the behaviors of one model, you can try switching to another (using the /model slash command) to see if it works better for you.