›_ Codex Issues
Codex Issues / #15347

Support moving/remapping a workspace folder without losing thread history

Open 💬 16 comments Opened Mar 20, 2026 by FreedomLabsIO
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

App

What feature would you like to see?

When a Codex workspace is moved or copied to a new folder, importing the new folder as an environment does not carry over the existing threads. The threads still exist locally, but they remain associated with the original workspace path, so the new environment appears empty.

This makes common workflows awkward, especially when moving projects from one drive to another for space reasons. Users expect project history to follow the workspace, but today the only workaround is a manual and unsupported local metadata rewrite.

Observed case:

Original workspace: C:\Users\Example\Downloads\ProjectAlpha
New workspace: D:\Work\ProjectAlpha
Result: existing threads did not appear in the new environment until local Codex state was manually edited
Why this happens:

Thread visibility appears to be path-keyed
At minimum, the stored workspace path is embedded in local thread/session metadata
Importing a copied folder creates a new environment instead of reattaching the old one
Suggested fix:

Add a Move workspace or Remap workspace path feature
Allow users to point an existing environment from an old path to a new path
Optionally support:
remap metadata only
move files and remap metadata
detect likely moved/copied workspaces and offer reattachment automatically
Expected behavior:

Existing threads should remain visible after a workspace is moved or copied and re-imported
Environment settings, trust state, and related project metadata should follow the remapped workspace
Impact:

Reduces confusion
Prevents project history fragmentation
Avoids unsafe manual edits to local Codex state

Additional information

_No response_

View original on GitHub ↗

16 Comments

github-actions[bot] contributor · 4 months ago

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

  • #13846
  • #14519
  • #13785
  • #14370

Powered by Codex Action

c99-dev · 3 months ago

Adding another repro in the same family as #15448 and #13846, and likely related to the Windows path-normalization root cause tracked in #10347.

I hit this on Windows while migrating existing projects from WSL-based paths to native Windows paths.

Example path transition:

  • old:
  • \\wsl.localhost\Ubuntu-24.04\home\cutshion\mega_tcp_server
  • \\wsl$\Ubuntu-24.04\home\cutshion\mega_status_server
  • /home/cutshion/mega_tcp_server
  • new:
  • C:\projects\mega_tcp_server
  • C:\projects\mega_status_server

What I observed:

  • the thread data was not lost
  • after partially updating saved workspace/project state, the threads could briefly reappear in the Desktop UI
  • after opening one of those restored threads, it could disappear from the project list again
  • the thread itself was still present and usable
  • the behavior only stabilized after all persisted cwd/workspace representations were aligned, not just one

Local evidence:

  • ~/.codex/state_5.sqlite contained thread cwd values in multiple forms, including \\?\C:\...
  • rollout/session files still contained historical cwd values in session_meta and turn_context
  • desktop global state also contained old workspace-root / thread-workspace-hint entries

So this seems slightly broader than “history missing after a move”. It looks like the same logical workspace can be represented in multiple path forms, and different code paths may group or re-bind threads using different persisted sources.

In my case, the same workspace ended up represented as:

  • \\wsl.localhost\...
  • \\wsl$\...
  • /home/...
  • C:\...
  • \\?\C:\...

The “visible at first, then disappears again after opening” symptom also feels very close to #15448.

My guess is that a durable fix likely needs both:

  • consistent normalization/canonicalization across persisted cwd/workspace sources
  • a user-facing re-link/remap recovery flow when the saved path no longer exists

If useful, I can provide a more explicit breakdown of which persisted files/records had to be updated before the behavior stopped reproducing.

bmccarthyco · 3 months ago

I accept #18174 as a dup as this was my original use case, renaming a physical directory and losing all the threads associated. I do think it can be expanded to include not just renaming of entire projects but also individual threads, e.g. cwd value should be updatable via App and CLI.

michft · 2 months ago

+1

claell · 2 months ago

This is a pretty important UX feature, so I can finally move folders around after once starting a Codex session in them, so I don't lose history or anything attached to it.

FahadBinHussain · 2 months ago

I put together a backend/app-server implementation for the storage side of this:

https://github.com/FahadBinHussain/codex/commit/2770047

Branch:
https://github.com/FahadBinHussain/codex/tree/feature-thread-metadata-update-cwd

Summary:

  • Adds cwd support to thread/metadata/update
  • Persists cwd updates through SQLite and rollout metadata
  • Updates loaded-thread state when applicable
  • Returns the refreshed thread after the metadata update
  • Updates protocol schemas, TypeScript schema output, README docs, and targeted tests

This does not add the Desktop UI relink/remap flow yet, but it gives clients a supported app-server API to re-home an existing thread to a new workspace path/project association.

Targeted tests passed in Windows Sandbox:

  • cargo test -p codex-state update_thread_cwd_updates_existing_row
  • cargo test -p codex-thread-store update_thread_metadata_sets_cwd_on_active_rollout
  • cargo test -p codex-app-server thread_metadata_update_moves_thread_to_cwd_and_returns_updated_thread --jobs 1

I tried to open an upstream PR, but GitHub shows that this repository only allows pull requests from collaborators. Happy to adjust the patch if maintainers prefer a different API shape or contribution path.

mahdi-rafiei · 2 months ago

+1

kidonng · 1 month ago

I wrote a Deno script to move Codex sessions from one directory to another: https://gist.github.com/kidonng/1cd60c58061b5b9540cb3c098095130a

Works for me, aside from the side effects of changing last update time.

helsharif · 1 month ago
I wrote a Deno script to move Codex sessions from one directory to another: https://gist.github.com/kidonng/1cd60c58061b5b9540cb3c098095130a Works for me, aside from the side effects of changing last update time.

how to use this script?

wangwren · 1 month ago

+1 for this.

ChatGPT Web already supports a “Move to project” action from the conversation menu, where you can move an existing chat into an existing project or create a new one.

I’d really like to see the same workflow in Codex Desktop. A lot of Codex threads start as projectless chats or in the wrong workspace, and only later become clearly tied to a specific project. Right now the workaround is to manually summarize/copy the context into a new thread, which breaks continuity.

Having a simple “Move to project” action would make organizing Codex conversations much easier and would match the existing ChatGPT Web behavior.

1Humza · 1 month ago

+1

creatornader · 1 month ago

Extremely strong +1 to this. I really need this feature.

PiN73 · 1 month ago

Solved with https://github.com/Adam-Bull/Codex-thread-toolkit from https://github.com/openai/codex/issues/11019

helsharif · 1 month ago
Solved with https://github.com/Adam-Bull/Codex-thread-toolkit from https://github.com/openai/codex/issues/11019

I have installed this plugin and was never able to successfully transfer chats to a new project following the instructions.

PiN73 · 1 month ago

@helsharif

> Solved with https://github.com/Adam-Bull/Codex-thread-toolkit from #11019 I have installed this plugin and was never able to successfully transfer chats to a new project following the instructions.

Make sure to manually create project at new folder location (before or after transfer)

helsharif · 20 days ago
@helsharif > > Solved with https://github.com/Adam-Bull/Codex-thread-toolkit from #11019 > > > I have installed this plugin and was never able to successfully transfer chats to a new project following the instructions. Make sure to manually create project at new folder location (before or after transfer)

I did this, and tried multiple times on a small example project and the plugin was not able to successfully transfer the chat. The plugin would claim to have accomplish the move, but after fully closing and restarting codex, the chats would remain with the old project. Maybe it would be useful to make a step by step video of using the tool, but I followed the instructions exactly.