›_ Codex Issues
Codex Issues / #7315

CLI command parsing deletes directories when chaining without a shell

Resolved 💬 11 comments Opened Nov 26, 2025 by gabrielecirulli Closed Mar 29, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

VS Code extension 0.4.46 (codex --version → codex-cli 0.63.0)

What subscription do you have?

Plus

Which model were you using?

gpt-5.1-codex-max

What platform is your computer?

macOS

What issue are you seeing?

At some point during my session, codex ran the command rm -rf apps/frontend/dist && ls apps/frontend. The command returned exit code 0 with no output in the Codex panel, and afterward the entire apps/frontend directory (except node_modules) had been deleted instead of only apps/frontend/dist.

I asked Codex to explain why this happened and it said the && tokens were passed as arguments to rm, causing it to recurse into apps/frontend. We tested this by running the command again and I observed that the directory was wiped again. I was able to restore my work via Git because I had no uncommitted changes, but this could have been catastrophic otherwise.

What steps can reproduce the bug?

1) From the repo root in the Codex panel/CLI, run:
rm -rf apps/frontend/dist && ls apps/frontend
2) The command completes with exit code 0 and no stdout/stderr.
3) Check the repo: apps/frontend now contains only node_modules; files like package.json, src, configs are gone.

What is the expected behavior?

  • Only apps/frontend/dist should be removed.
  • apps/frontend and its contents should remain intact.
  • The listing (ls apps/frontend) should show the app files.
  • A destructive deletion of the entire app should not occur silently.

Additional information

  • Environment: VS Code extension v0.4.46; codex-cli 0.63.0; macOS arm64.
  • The same command, when run with an explicit shell wrapper (bash -lc 'rm -rf apps/frontend/dist && ls apps/frontend'), produces normal output and does not delete apps/frontend.
  • Workaround: use bash -lc '…' or run each step separately to avoid the unintended deletion.
  • To prevent this for now I added a note to AGENTS.md for Codex to avoid issuing commands this way.

What follows is the CoT and commands issued at the time of the issue.

<img width="562" height="1291" alt="Image" src="https://github.com/user-attachments/assets/2078e188-8a31-41c8-a72a-fbe9a77c898e" />

This is how I verified that the command was the culprit.

<img width="558" height="520" alt="Image" src="https://github.com/user-attachments/assets/0979ef66-1687-4c9c-8a32-abc96ed859dc" />

View original on GitHub ↗

11 Comments

github-actions[bot] contributor · 7 months ago

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

  • #7080
  • #6997
  • #6940

Powered by Codex Action

gabrielecirulli · 7 months ago

After enabling unified_exec = true I am observing the following behavior. Note that in this case no unintended files were removed. However, strangely, Codex reports receiving no output even though it chained the command with ls

<img width="1124" height="624" alt="Image" src="https://github.com/user-attachments/assets/207d8e0d-8fe1-40d2-b4b4-918987bed150" />

gabrielecirulli · 7 months ago

More strange behavior: pwd is / (before unified_exec = true it was my repository's directory)

<img width="1138" height="1270" alt="Image" src="https://github.com/user-attachments/assets/83f8926d-584b-498a-a613-7dcae857dbc6" />

gabrielecirulli · 7 months ago

I can confirm that the issue persists with unified_exec = true: Once the pwd issue was fixed, Codex was still able to wipe my entire apps/frontend directory. Blacked out path is the full absolute path to the root of my monorepo.

<img width="554" height="572" alt="Image" src="https://github.com/user-attachments/assets/7a9ae3a4-dba5-479e-8fc9-73a0fba251a3" />

gabrielecirulli · 7 months ago

Please note that I cannot reproduce the above when using Codex CLI from the terminal.

lionel-oai contributor · 7 months ago

Hi @gabrielecirulli I just tried your prompt and it seems to have worked for me but for me codex decided to run it with explicit shell (/bin/zsh -lc 'rm...). Which shell are you using?

<img width="1533" height="565" alt="Image" src="https://github.com/user-attachments/assets/9d1c7cb8-63af-4c31-86b1-e599b5a9fa8a" />

etraut-openai contributor · 7 months ago

Thanks for the bug report. This appears to be 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.

gabrielecirulli · 7 months ago

Hi @lionel-oai —

In my terminal:

❯ dscl . -read ~/ UserShell
UserShell: /opt/homebrew/bin/fish
❯ echo $SHELL
/opt/homebrew/bin/fish

Within the Codex VSCode extension:

<img width="1122" height="1096" alt="Image" src="https://github.com/user-attachments/assets/6cef65c5-416b-4599-9c0b-d7c6de66bc89" />

--

@etraut-openai given the above, are you sure this is a model behavior issue?

It seems more likely that the system is not able to use fish properly, or there is some other incompatibility here.

Would you be willing to reopen the issue?

gabrielecirulli · 7 months ago

Interestingly, codex used as a CLI also uses fish for command execution, however it does not suffer from this issue or from issue #7317 as far as I've been able to observe. The issues seem limited to the VSCode extension.

I therefore wonder if the fish interaction is a red herring. (excuse the pun 😆)

lionel-oai contributor · 7 months ago

Would you mind switching to zsh and try out your rm -rf to see if it works by changing shell :)?

etraut-openai contributor · 3 months ago

This bug report hasn't received any upvotes or additional posts in five months. Closing.