Allow existing threads to update working directory after project folder rename

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

• #25498

Powered by Codex Action

Thanks for the duplicate pointer. I reviewed #25498.

This issue is related, but the requested flow here is a narrower recovery path: an existing thread already has a project/working-directory binding, the local folder is renamed or moved, and Codex then reports the working directory as missing. The user needs a safe way to repoint that same thread to the new path without creating a new thread or manually recreating the old path with a symlink.

#25498 covers broader project management, including registering projects and moving/changing project bindings. If that work would include a missing-directory recovery prompt or a direct "update this thread's local working directory" action, then this issue can be closed as covered by #25498. Otherwise, this issue can serve as the focused acceptance case for folder rename/move recovery.

This seems closely related to this focused recovery path, with a symlink-specific variant.

In my case, the project was originally opened through a symlink path:

<old-project-alias-path> -> <real-project-path>

I later removed the symlink while keeping the real project directory intact. After that, Codex Desktop made the existing project chats appear to be missing from the project chat list, even though the session history still existed locally.

The workaround was similar in spirit to recreating the old path: either recreate the symlink, or manually update the saved cwd/project metadata from the removed symlink path to the real project path.

So I think the same recovery flow would solve this case too:

• detect that the saved cwd no longer exists
• allow the user to repoint the existing thread/project to a new local path
• preserve chat history and thread continuity
• avoid requiring a compatibility symlink just to satisfy stale cwd metadata

The symlink-specific case may also benefit from storing both the literal cwd and the resolved realpath, or warning when a project is opened through a symlink.

One additional observation from this case: after manually updating the saved cwd metadata, different parts of Codex Desktop did not immediately agree on the updated state.

For example, the thread list/search result showed the updated real project path, while reading the individual thread still appeared to return the old symlink path for a while. After additional metadata/config cleanup and refresh, the UI eventually became consistent again.

So this may not only require a "repoint this thread to a new working directory" action, but also a consistent metadata refresh/reconciliation step across thread list, search, and thread detail state.

I’m seeing the same Windows/Desktop failure mode after moving a project folder, with a short screen recording showing the affected thread UI.

Environment:

• Codex Desktop for Windows x64
• Version: 26.707.3748.0
• Original project path: C:\Users\<user>\OneDrive\Documentos\invierte.col
• New project path: C:\Users\<user>\OneDrive\Documentos\PRACKTICE PROJECT\CLIENTS REPOS (DO NOT TOUCH)\invierte.col

Repro:

1. Open an existing Codex thread from the original folder.
2. Move/rename that folder to the new location.
3. Return to the existing thread in Codex Desktop.

Observed:

• The existing thread remains tied to the old workspace/path and continues displaying stale thread/plan/preview context instead of cleanly attaching to the moved project.
• The short recording I captured does not contain an audible error or a readable error string; the visible symptom is the stale workspace/thread state after the move.

Expected:

• Codex should detect that the saved working directory moved, let the user locate/repoint it, and refresh all project/thread views consistently while preserving the conversation history.
• It should not require recreating the old path or starting a new thread as the only recovery.

Workaround:

• Reopen the project from its new location (or recreate the old path), but that loses the seamless continuity this existing thread should provide.

This looks like a concrete Desktop reproduction of the working-directory remapping/reconciliation issue described here.

I built a small portable Agent Skill + standalone Python CLI for this exact workaround on Windows: safely relinking Codex Desktop/CLI workspace history after a project folder is moved or renamed.

Repository: https://github.com/paultheal1en/relinking-codex-workspaces-skill

It provides:

• read-only dry-run first;
• timestamped backups of affected Codex state files;
• structured replacement of old workspace paths;
• post-migration verification;
• rollback instructions;
• no SQLite database modifications.

This is an unofficial workaround that edits Codex's local state, so users should close Codex first, inspect the dry-run output, and keep the generated backup until the migrated workspace is verified.

I hit the same issue on Codex App 26.715.52143, macOS 26.5.2 on Apple silicon, when replacing a temporary local checkout with its stable repository path.

This was a bulk case: 23 existing threads were still bound to the old root. The transcripts remained on disk, but there was no supported UI or command to reattach those threads to the new local project.

To preserve the histories, I first created timestamped backups and then had to reconcile several layers of local state:

• SQLite thread working-directory values and saved sandbox policies
• rollout session_meta and turn_context working-directory metadata
• saved and active workspace roots plus the local-project selection in the app state

After the migration, I verified that:

• all 23 original thread IDs were present under the new root
• no migrated thread or sandbox policy retained the old root
• the SQLite database and rollout JSONL files were valid
• the new local project showed 24 chats: the 23 migrated chats plus one chat already created there

This seems like a useful bulk acceptance case for the feature:

1. When a saved project root is missing, offer a Relocate/Reattach project action.
2. Let the user update either one thread or all threads bound to the old root.
3. Apply the change atomically across thread, sandbox, indexing, rollout, and project metadata.
4. Refresh the sidebar, search results, and thread detail views consistently.
5. Preserve chat history, validate the replacement directory, and ensure the updated sandbox roots do not broaden access.
6. Create a recoverable backup or transaction rollback point before applying a bulk migration.

A first-class workflow would avoid unsupported manual state edits or compatibility symlinks.