Bug: Codex Sessions Refuse to Continue Session

[adamatan]

I get these codex messages quite often recently. Clicking R does not help, and I did not open them in any other app. They don't even have another agent in their worktree.

Any idea why this happens, and whether it's a Termic issue?
I'm using the latest 1.3.6 version.

Thanks!

Agent Analysis

Observed behavior:

• Five concurrent termic new --wait calls targeted different task names.
• Each command exited 1, claiming its newly created branch already existed.
• Despite the errors, all five tasks, branches, worktrees, and Codex sessions were created.
• Some sessions then showed “This conversation is open in another app.”
• Task status briefly disagreed with actual activity, and tab IDs became temporarily unusable.

Expected behavior: concurrent creates should each succeed once, or fail without leaving partial state or duplicate session ownership.

[simion]

Reproduced this, and part of it is ours.

Codex takes a writer lock per conversation.
If a second Codex process has your thread open, the first one refuses.
Driving two of them at the same thread, the second exits with thread <id> already has an active writer in about 450ms.
Good news: killing the holder frees it immediately, so a leftover lock file blocks nothing and nothing is permanently stuck.

The Termic bug is what happens next.
That 450ms exit is well inside the window we use to notice a failed resume, but two checks were written against a code path Codex never takes (it can resume a session by id but cannot be told one at launch, which puts it in a different branch).
So the exit was ignored, the tab quietly started a fresh session instead, and it never told you why.
That is why R did not help: it respawned into the same thing every time.

Fixed in 85a86d0, going out in today's release.
A failed resume now says so and stops retrying the id that failed.

What I have not worked out is what was holding your threads open in the first place, and that is the part your five parallel termic new --wait calls probably explain.
If you hit it again, codex --version and the exact stderr from one of the failing commands would help a lot.

In the meantime, if a task gets stuck like this: close the agent tab and open a new one rather than pressing R.
The session id is per tab, so a fresh tab starts clean.

[adamatan]

Thanks! Much appreciated.

[simion]

Released in v1.3.7, just now.

Closing this, since the half that was ours is fixed: a failed resume is reported instead of silently starting a fresh session.
What I still have not pinned down is what was holding those threads open in the first place.
If it comes back on 1.3.7, reopen with codex --version and the stderr from a failing command and I will pick it up from there.