The application panicked (crashed). Message: /tmp is absolute: Os { code: 2, kind: NotFound, message: "No such file or directory" }

What version of Codex CLI is running?

0.111.0

What subscription do you have?

pro

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 6.18.8-arch2-1 x86_64 unknown

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

st (suckless terminal), tmux 3.6a

What issue are you seeing?

The odd characters going down the left is what it showed. As it continued and I tried typing a message to queue, my characters were also just going down the left side. After finishing, I can type normally but need to press enter twice to send.

• I hit a patch formatting issue. I’m reapplying the base edits now and then I’ll commit the rebuilt first step.

• Working (29s • esc to interrupt)


› The application panicked (crashed).
Message:  /tmp is absolute: Os { code: 2, kind: NotFound, message: "No such file or directory" }
L
• Working  37
B
R
WaThe application panicked (crashed).
Message:  /tmp is absolute: Os { code: 2, kind: NotFound, message: "No such file or directory" }
L
• Working   8
B
R
WaThe application panicked (crashed).
Message:  /tmp is absolute: Os { code: 2, kind: NotFound, message: "No such file or directory" }
L
• Working  42
B
R
WaThe application panicked (crashed).
Message:  /tmp is absolute: Os { code: 2, kind: NotFound, message: "No such file or directory" }

• apply_patch is failing on this workspace, so I’m falling back to in-place text edits with shell commands to keep the rewrite moving. I’m limiting that to the
  exact line changes we agreed on.

What steps can reproduce the bug?

No idea.

What is the expected behavior?

It shouldn't panic or crash. It either didn't crash, or it recovered. It seems to have finished just fine, but I haven't seen it do anything like this before and there are unresolved issues from other users who never responded without /feedback sent, so I wanted to report this.

Additional information

/feedback thread ID 019ccf89-2381-7ad0-8297-1fc4492724be.

I'm going to leave this Codex session running where it's at and continue in another, in case there's anything else I can run in it to help diagnose this, although I doubt there is.

Related issues:

• https://github.com/openai/codex/issues/8428 - Closed by reporter, not sure why.
• https://github.com/openai/codex/issues/10297 - Reporter never responded to your question.
• https://github.com/openai/codex/issues/12247 - Reporter gave reproduction steps which were complicated.

I have no idea what happened. journalctl doesn't show any actual errors. I have a ton of other things running, and nothing else had complaints. I've never seen a /tmp error from any application before, or encountered any type of permission denied or operation not permitted error with it in a shell or another program. Codex has been using /tmp a lot lately (I kind of wish it didn't, or that it was scoped to /tmp/<codex session id> to prevent collisions) and I haven't seen problems with it. No other Codex session was doing anything, so there was no collision.

I am on Arch Linux. There's no special or unusual environment. It's not a VM, and I'm not using any type of sandboxing.

I asked Codex what it could tell me, and below is that conversation. I don't even think my fingers were on my keyboard when it errored, and even if I had, I'm not sure why it should have shown this error. If I had interrupted it like it claims, I don't think it would have continued and completed its work. It claims it stopped and I asked it to restart, but that's not what happened and isn't what the TUI shows scrolling up.

---

› What were you trying to do when we had the application panicked crashed errors regarding /tmp? What was the error? What can I tell OpenAI in a bug report to
help them know exactly what happened?

• I was trying to get an untracked panel-of-experts/ directory out of the repo so I could switch back to master and restart the history rewrite from the correct
base.

The sequence was:

1. I was on the wrong branch: rewrite_discussed_changes, which pointed at unrelated commit 57da9fb stash: clean_architecture.
2. On that branch, panel-of-experts/ was untracked, because the files had been restored there without being committed on that branch.
3. git switch master failed with this Git error:

error: The following untracked working tree files would be overwritten by checkout:
panel-of-experts/SKILL.md
panel-of-experts/scripts/panel_of_experts.py
Please move or remove them before you switch branches.
Aborting

1. To recover, I tried to move that untracked directory out of the repo into /tmp, with a command like:

mv /mnt/fast/skills.git/panel-of-experts /tmp/panel-of-experts-rewrite-backup-20260310

Later I used:

mv /mnt/fast/skills.git/panel-of-experts /tmp/panel-of-experts-wrong-base-20260310

What the actual error was:

• I did not get a shell error from mv itself.
• The first mv attempt was aborted/interrupted.
• If the application showed a panic/crash mentioning /tmp, that was app-side behavior around handling that move, not a normal command failure that I could see

from the shell.

What to put in a bug report:

• Repo cwd: /mnt/fast/skills.git
• A nested directory panel-of-experts/ existed as untracked files on branch rewrite_discussed_changes
• That branch pointed at unrelated commit 57da9fb stash: clean_architecture.
• git switch master failed because tracked files on master would overwrite untracked files:
• panel-of-experts/SKILL.md
• panel-of-experts/scripts/panel_of_experts.py
• Recovery action attempted:
• mv /mnt/fast/skills.git/panel-of-experts /tmp/panel-of-experts-rewrite-backup-20260310
• The crash/panic happened around that /tmp move attempt, not around a Git command
• The move was being run as an escalated command from the coding agent
• The first attempt was interrupted/aborted; a later move to /tmp/panel-of-experts-wrong-base-20260310 succeeded

If you want, I can also write this up as a compact bug report you can paste directly.

› Why was the first mv attempt aborted/interrupted? I didn't do that.

• I can’t actually tell that you personally did it.

What I know is only this:

• The first mv command returned from the tool as aborted by user.
• Immediately after, the system injected a message saying:

<turn_aborted>
The user interrupted the previous turn on purpose.
Any running unified exec processes were terminated.
If any tools/commands were aborted, they may have partially executed; verify current state before retrying.
</turn_aborted>

So from my side, the platform reported it as a user interruption. But that does not prove you clicked anything intentionally. It could also have been:

• a UI misfire
• a transport/session interruption
• an internal tool/runtime cancellation that was mislabeled
• some other app-level abort condition surfaced as “user interrupted”

So for a bug report, I would say:

• I did not observe a shell error from mv.
• The command was terminated by the tool/runtime and surfaced as aborted by user.
• The system then emitted a <turn_aborted> event claiming the user interrupted the turn.
• The actual human user says they did not intentionally interrupt it.

That is a useful detail for OpenAI, because it points at a possible misattribution bug in the interruption/cancellation path rather than a normal command
failure.

› Run some test commands on files not actually involved in this project; make temporary ones as needed. See if you run identical commands that had problems
earlier if they succeed or fail the same way.

...

• I tested the same patterns on disposable files and repos. The results point away from mv itself and toward the earlier interruption being app/runtime-side.

Findings:

• Plain mv on throwaway directories in /tmp succeeded.
• A closer analogue, moving a throwaway directory from /mnt/fast/skills.git/panel-of-experts/... to /tmp/..., also succeeded.
• I reproduced the earlier Git error exactly in a disposable repo:
• git switch failed with:

error: The following untracked working tree files would be overwritten by checkout:
panel-of-experts/SKILL.md
panel-of-experts/scripts/panel_of_experts.py
Please move or remove them before you switch branches.
Aborting

• I then ran the same recovery pattern there:
• mv /tmp/poe-git-switch-test/panel-of-experts /tmp/poe-git-switch-test-moved
• retry git switch withdir
• That recovery succeeded immediately.

What this suggests:

• The earlier Git failure was normal and reproducible.
• The filesystem move itself is also normal and reproducible.
• I did not reproduce any crash or panic around moving to /tmp.
• So the earlier /tmp incident still looks like a platform/tool interruption that was surfaced as aborted by user, not a normal shell-level mv failure.

If you want to report it, the strongest summary is:

• git switch was correctly blocked by untracked files that would be overwritten.
• The intended recovery was to mv the untracked directory to /tmp.
• The same recovery works in a disposable reproduction.
• In the real session, that mv was interrupted by the app/runtime and labeled aborted by user, even though the user says they did not interrupt it.

› If I had interrupted it, wouldn't you have stopped and not finished up the work?

• Yes, normally.

If you had actually interrupted the turn, I would not have been able to continue that turn to completion. What should happen is:

1. the running command gets canceled
2. the turn ends
3. I wait for your next message

That is basically what the system claimed happened when it emitted the <turn_aborted> event. I did not continue the original turn after that. I only resumed
once a new user message came in.

So the suspicious part is not “why did the work continue anyway?” It didn’t. The suspicious part is:

• the tool reported aborted by user
• the system reported user interrupted the previous turn on purpose
• you say you did not do that

That combination suggests a false or misattributed interruption event, not that I ignored a real interruption.