Codex Thread Already Has an Active Writer? Resume Safely

If Codex says a thread "already has an active writer," do not delete the session or start several resume attempts. Choose one surface to own the conversation, fully quit the other surface, and resume the thread once from the intended owner.

Fresh reports against Codex 0.147 show the same boundary on macOS and Windows: closing the desktop window or switching conversations can leave the app holding the thread, while fully quitting the desktop app allows the standalone CLI to resume it. That is evidence of an ownership conflict, not proof that the transcript is corrupt.

The Safe Fix in 60 Seconds

1. Save any unsent prompt and let the current turn finish.

2. Decide whether Codex Desktop or the standalone CLI should own the thread next.

3. Fully quit the other surface. On Windows, also exit Codex from the system tray.

4. Resume the thread once:

   codex resume <session-id

5. Ask Codex to summarize the last completed turn without changing files.

6. Continue only if the summary and working tree match what you expected.

This is a controlled handoff, not a confirmed upstream fix. Keep only one writer attached to the conversation until the tracked issues or release notes confirm different behavior.

Match the Error Before Changing Anything

Use this guide when all of these are true:

• Codex reports that the thread already has an active writer, sometimes inside an error with code -32600.

• The same conversation was recently open in Codex Desktop, Remote, or another CLI process.

• The problem affects resuming an existing conversation, not starting a new one.

• Fully quitting the current owner changes the result.

The current macOS report describes a Desktop, Remote, and CLI conversation that the CLI could not resume until Desktop was fully quit. The Windows report says opening a conversation in the 0.147 alpha kept its writer active even after switching conversations, waiting, and closing the window. Exiting the tray app released it.

Do not apply this procedure to every resume failure. If the conversation still cannot resume when every other Codex surface is normally closed, the active-writer regression is not confirmed. Authentication, a missing session, an incompatible version, or a different local-state problem may need separate diagnosis.

Do Not Repair the Session Files

An ownership error is a reason to reduce writers, not to edit storage. Before the handoff:

• do not delete, rename, truncate, or rewrite files under ~/.codex/sessions;

• do not copy a live JSONL file over another session;

• do not launch multiple resume commands against the same thread;

• do not disable Remote or reset authentication as a first step;

• do not force-kill background processes while Codex is writing a turn.

The strongest evidence in the current reports is that a normal full quit releases the conversation and the unchanged session becomes resumable. Preserve that evidence. If disk usage is the separate problem, follow the Codex session JSONL cleanup guide instead of improvising inside a live session.

Choose One Owner

Write down which surface should continue the conversation:

OpenAI's Remote documentation describes continuing chats on a connected Mac or Windows host. The active-writer reports show why the direction of the handoff matters: continuity does not mean two surfaces should write the same conversation at the same time.

Fully Quit Codex Desktop

Closing a window is not the same as quitting the application.

On macOS, use the application menu and choose Quit, or press Command-Q. Wait for Codex Desktop to finish closing normally.

On Windows, close the window, open the system tray, and choose Exit or Quit for Codex. Confirm that the tray icon is gone. The Windows reproduction specifically reports that closing the window left all opened threads held until the tray application exited.

Avoid kill -9, Task Manager's process-tree termination, or deleting app data for this first recovery. A normal quit gives the current owner a chance to flush state and release the thread cleanly. If the app will not quit normally, treat that as a separate application-lifecycle problem and preserve diagnostic evidence before escalating.

Resume Once From the CLI

After the other owner is fully closed, resume the specific conversation:

codex resume <session-id

If you need to find an older conversation in the picker, use:

codex resume --all

For a non-interactive continuation, Codex also supports:

codex exec resume <session-id> "Summarize the last completed turn. Do not change files."

Prefer the interactive resume as the first canary. It makes the ownership boundary visible and avoids dispatching new work before you know the thread reopened correctly.

Do not loop the command. If the first attempt still reports an active writer, stop and recheck whether Desktop, its tray process, Remote, or another terminal still owns the conversation.

Verify Context Before Continuing

The first prompt should be read-only:

Summarize the last completed turn, the current task, and any pending decisions. Do not run tools or change files.

Then verify the repository independently:

git status --short

Continue only when the summary is coherent, expected files are present, and the working tree contains no unexplained changes. This check does not prove every transcript event is intact, but it catches the most important handoff failure before Codex edits the project.

If the summary is stale or incomplete, exit normally and preserve the session. Record the session ID, Codex versions, operating system, exact error, and which surface last completed a turn. Do not try to splice transcript files together.

Hand the Thread Back to Desktop

Use the same one-owner rule in reverse:

1. Let the CLI finish its current turn.

2. Exit the CLI normally.

3. Launch Codex Desktop.

4. Open the conversation once.

5. Use a read-only summary prompt before starting new work.

This sequence is a conservative operating procedure inferred from the reported ownership boundary. The upstream issues do not yet establish a permanent fix or promise that every surface releases threads identically.

If the Conflict Persists

Fully quit every Codex surface, wait for normal shutdown, and open only the intended owner. If that owner still cannot resume the conversation, stop classifying the failure as the confirmed active-writer case.

Capture:

• Codex Desktop and CLI versions;

• stable versus alpha release channel;

• macOS or Windows version;

• the exact command and complete sanitized error;

• whether a normal full quit changed the result;

• whether a new disposable conversation works;

• whether the same session can be listed but not resumed.

Add that evidence to the matching upstream issue rather than opening a duplicate. Never post account tokens, local paths that identify a user, proprietary prompts, or session transcripts.

Watch the Codex releases and the two current reports. Retest with one disposable conversation after an issue or release note changes. A successful retest requires both directions of the handoff to complete without an ownership error and without modifying session storage by hand.

Monitor the Regression With a Read-Only Action

Aident Loadout can monitor the upstream reports without giving the agent permission to change them. It keeps discovery, schema inspection, cost preflight, credentials, and execution behind one governed capability boundary.

Give Codex the canonical setup instruction:

Follow https://aident.ai/SETUP.md

Then use this prompt:

Check my Aident Loadout account authentication and Vault status. Search the staging capability catalog for a connected read-only GitHub issue-search Action, inspect its current schema, and preflight it. If the estimate is free, return only the state, updated time, title, and URL for openai/codex issues 37403 and 37450. Do not comment, edit, close, label, publish, install, change files, start OAuth, or request a GitHub token.

Success is measurable: the two issue records are returned, the action receipt shows a read-only search, and no GitHub write occurs. Set up Aident Loadout and monitor the writer-handoff regression.

Sources

• OpenAI Codex issue 37403: Desktop, Remote, and CLI active-writer conflict on macOS

• OpenAI Codex issue 37450: Desktop keeps opened threads active on Windows

• Official OpenAI Codex Remote documentation

• Official OpenAI Codex CLI reference

• Official OpenAI Codex releases

Refresh this guide when either tracked issue changes state, OpenAI documents the ownership lifecycle, or a stable Codex release passes the two-direction handoff test.