[Regression][Desktop 26.818 / CLI 0.149] Resumed thread restores deleted pre-rename workspace root

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.818.41509

What subscription do you have?

Plus

What platform is your computer?

macOS 15.7.7 (24G720)

What issue are you seeing?

A long-running Codex Desktop thread restores an obsolete workspace root after the repository folder was renamed and the project’s primary source folder was updated.

Old path:

~/Library/CloudStorage/Dropbox/CODING PRODUCTION/AleksTape

Current path:

~/Library/CloudStorage/Dropbox/CODING PRODUCTION/VST Development/ALXTape

The thread continued working normally for approximately two to three weeks after the rename. The failure appeared only after updating to Desktop 26.818.41509, bundled Codex CLI 0.149.0-alpha.4.1.

The project settings correctly show the new path, but the resumed thread restores the deleted old path as its writable workspace root. Commands can read the repository when given the new path explicitly, but apply_patch cannot edit it.

Selecting Full Access also did not update the effective thread environment: the next turn still received a managed workspace-write profile containing only the old path.

What steps can reproduce the bug?

1. Create a Codex Desktop project and thread while a repository is located at path A.
2. Rename or move the repository to path B.
3. Update the project’s primary source folder in Codex Desktop to path B.
4. Continue using the existing thread after the rename.
5. Update Codex Desktop to 26.818.41509 and resume the existing thread.
6. Ask Codex to modify a file under path B.
7. Observe that the thread restores path A as its writable workspace root.
8. Select Full Access and send another turn.
9. Observe that the thread still receives the old managed workspace-write profile.
10. The exact update boundary may be relevant: this thread worked after the rename until the recent update.

What is the expected behavior?

When an existing thread is resumed, Codex should reconcile its saved workspace root with the project’s current primary source folder.

If the stored root no longer exists, Codex should prompt the user to locate or rebind the moved repository.

A permission mode explicitly selected by the user, including Full Access, should also become the effective permission state for the next turn rather than being replaced by stale per-thread settings.

The thread history should remain usable without recreating the old path, editing internal Codex state, or starting a new thread.

Additional information

The repository at the new path exists, is recognized correctly by Git, and has a clean working tree. The old path no longer exists. No repository files were modified while diagnosing the problem.
This may relate to Codex CLI 0.149.0 changing resumed and forked threads to restore their active permission profile instead of falling back to current defaults:
https://github.com/openai/codex/pull/39153
Related reports:
• https://github.com/openai/codex/issues/20934
• https://github.com/openai/codex/issues/15347
• https://github.com/openai/codex/issues/22075
• https://github.com/openai/codex/issues/33886
The relationship to PR #39153 is suspected from the timing and observed state; it has not been confirmed as the root cause.

Start by reviewing PR #39153 and the related reports #20934, #15347, #22075, and #33886, then reproduce the path-rename and thread-resume sequence described here. Trace how resumed threads restore their workspace root and permission profile across Codex Desktop and CLI 0.149. Done means the current path and an explicitly selected permission mode are used when the old root no longer exists, without recreating the thread.