Repository navigation
[Windows][Codex Desktop] Existing task retains deleted workspace path after project folder is moved #41776
Description
Summary
On Windows, an existing Codex Desktop task keeps its original workspace path after the project directory is moved or renamed outside Codex. Restarting the desktop application restores the same task with the stale path instead of detecting that the workspace moved or asking the user to select its new location.
This leaves the task in a partially functional state:
- commands without an explicit working directory fail because the persisted cwd no longer exists;
- commands with an explicit new working directory can still run;
- file inspection, builds, and tests may work against the new directory;
- the managed patch editor rejects files in the new ordinary directory with a misleading
path contains a reparse pointerror; - restarting the application does not repair or rebind the task.
No repository, username, private path, credentials, or project-specific content is included in this report.
Environment
- Surface: Codex Desktop
- Platform: Windows x64
- OS family observed: Windows 10
- Workspace type: local directory
- Date observed: 2026-08-31
- The old and new directories were on the same local NTFS volume.
- Neither project directory was intended to be a symlink or junction.
Steps to reproduce
- Open a local project directory in Codex Desktop, for example:
D:\Workspace\OldProjectName - Start a task and perform normal file/build operations.
- Move or rename the project directory outside Codex:
D:\Workspace\OldProjectName→D:\Workspace\NewProjectName - Continue the existing task.
- Restart Codex Desktop and reopen the same task.
- Ask the task to run a command without an explicit working directory.
- Ask it to edit a file under the new directory using the managed patch mechanism.
Actual behavior
The task remains bound to the deleted original path.
A command using the task default cwd fails before the shell starts:
CreateProcessAsUserW failed: 267 (The directory name is invalid.)
cwd=D:\Workspace\OldProjectName
When an explicit workdir=D:\Workspace\NewProjectName is supplied, shell commands can read, build, and test the moved project successfully.
However, the managed patch operation against a normal file under the new directory fails with:
Failed to read file to update D:\Workspace\NewProjectName\README.md:
path contains a reparse point
Independent filesystem inspection shows that the new project directory and its parents are ordinary directories, not reparse points.
Restarting the application restores the same stale workspace binding. Repeated restarts do not prompt for the new location and do not update the task cwd.
Expected behavior
When reopening an existing task whose workspace path no longer exists, Codex Desktop should:
- detect the missing workspace before starting tool execution;
- offer to locate/rebind the moved project;
- validate and persist the newly selected canonical path;
- update the task cwd and managed filesystem scope together;
- distinguish an out-of-workspace path from an actual symlink/junction/reparse point;
- avoid restoring the task into a partially functional state.
If automatic rebinding is unsafe, the task should fail closed with an actionable message such as:
The original workspace no longer exists. Select the project's new location or create a new task.
Impact
Long-running tasks lose practical continuity after a legitimate local project rename or product rebranding. Users can still run some explicit-workdir commands, which makes the task appear usable, but managed edits remain blocked and error messages incorrectly suggest filesystem indirection.
This can also leave the old directory locked while the task is open, complicating cleanup and making diagnosis confusing.
Suggested hardening
- Persist a stable workspace identity in addition to the raw path where possible.
- On resume, verify that the canonical workspace exists before restoring the task.
- Add an explicit Rebind workspace action for existing tasks.
- Update command cwd, sandbox roots, trust state, file-edit scope, watchers, and UI project metadata atomically.
- Report separate errors for:
- missing original workspace;
- path outside the authorized workspace;
- actual reparse point;
- stale watcher or task binding.
- Add a Windows integration test covering same-volume directory rename followed by app restart and task resume.
Workaround
Create a new Codex task opened directly on the renamed project directory. Restarting the existing task or application is not sufficient.
Activity
github-actions commentedon Aug 31, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
develmax commentedon Aug 31, 2026
Additional findings from local investigation:
%USERPROFILE%\.codex\state_5.sqlite, tablethreads, columncwd.%USERPROFILE%\.codex\sqlite\codex-dev.db, tablelocal_thread_catalog, columncwd.projects/project_roots; only the existing task/thread rows still referenced the removed directory.cwdandproject_idin both stores, and restarting Codex Desktop, the original task resumed successfully in the renamed directory.workdirthen started in the new workspace, and the solution file was accessible.This confirms the problem is persisted task/catalog metadata rather than an NTFS reparse point. It also suggests a rebind operation needs to update both stores atomically (plus any sandbox/file-edit authorization state), ideally through a supported UI action rather than manual database edits.
Manual SQLite editing is only a diagnostic workaround and should not be recommended as a normal recovery path, especially while Codex Desktop is running.
develmax commentedon Aug 31, 2026
Thanks. I reviewed #41508. The two reports are related at the workspace-refresh/rebinding layer, but they are not duplicates:
cwdeven after Codex Desktop is restarted.workdiris supplied explicitly, while the managed editor reports a misleading reparse-point error.cwdandproject_idin both stores, followed by an app restart, restored the original task.The issues may share missing workspace-state invalidation, but they require different recovery behavior: #41508 should refresh a temporarily unavailable path, while this issue needs an explicit and atomic rebind from an obsolete path to a new canonical path. I therefore believe this issue should remain separate.
martinabel234 commentedon Oct 13, 2026
Independent Windows reproduction on 2026-10-13: stale project cwd also prevents Chrome control
This adds browser-runtime impact to #41776. The user explicitly requested escalation after repeated unsuccessful recovery attempts and chats inheriting the obsolete project directory.
The user is currently continuing work in another open chat using a temporary workaround tied to an existing folder. They explicitly request that reporting/diagnosis must not restart the app, terminate helpers, change connector configuration or otherwise interrupt that working chat. This workaround is not evidence of a general product fix.
Environment verified
Observations
Requested resolution
Please provide a supported way to rebind an existing chat and the saved project to an existing folder while preserving history and effective permissions. Detect missing directories before accepting browser work, and keep browser-helper launch directories independent of user projects. New chats should not silently inherit a nonexistent source directory. Verify recovery with a real Chrome tab read in the affected chat, across restart and subsequent chats; MCP initialization alone is insufficient.
Related reports reviewed: #44736 (helper cwd erased by startup), #48534 (versioned CUA cache invalidates workaround), and #50143 (deleted helper cwd breaks browser policy bridge on Linux; related mechanism, not the same Windows reproduction).
This report excludes personal file paths, project/song names, account identifiers, raw conversation logs and credentials.
k-kostin commentedon Oct 17, 2026
Additional macOS evidence for #41776: correcting saved cwd is necessary but can leave stale Desktop write grants.
Environment observed on 2026-10-17: ChatGPT Desktop host 26.1007.71326 (build 20398), bundled Codex CLI 0.162.0-alpha.17.2; a separate PATH CLI was 0.163.0. Both used the same local Codex home.
We recovered 21 existing, explicitly selected ordinary project chats after a project move from
<HOME>/Documents/ProjectAto<HOME>/Projects/ProjectA. The old directory no longer existed. The Desktop project association, thread cwd, explicit tool workdir, and effective filesystem permissions had to be checked separately. We did not rerun a clean project-move reproduction, so this reports a recovered existing state rather than proof of the initiating UI action.Useful findings:
thread-writable-rootsin.codex-global-state.json. On return to Desktop, the old project path and an unrelated project path were present again in effective write scope, despite the cwd repair. This is not evidence of unauthorized file access; these were existing retained grants whose intended scope we explicitly narrowed.threads.project_id; joining only on that column would have missed them. We also found many internal rows carrying the old cwd, which were excluded from the migration allowlist.Acceptance after reopening Desktop: all 21 selected chats ran a default-cwd command without an explicit workdir and performed temporary write/read/delete probes in intended roots. Latest per-turn effective write profiles and retained grants were checked for removed paths and broader writable ancestors. The same IDs and original logical transcript prefixes were preserved. Read permission was not revoked or claimed to be revoked.
Suggested regression contract for a supported rebind action:
Related worktree case: #41835 . We did not reproduce that remote-worktree bug locally. Raw private state/transcripts are intentionally omitted.
k-kostin commentedon Oct 17, 2026
Follow-up to my earlier macOS report: two additional legacy CLI chats exposed a project-association gap during recovery.
Same environment, observed on 2026-10-17: ChatGPT Desktop host 26.1007.71326 (build 20398), bundled Codex CLI 0.162.0-alpha.17.2. These two chats originated in CLI 0.104.0 and had no Desktop project assignment.
Their cwd recovery succeeded while preserving both original thread IDs and history. In Desktop, both subsequently executed commands in the intended default directory and passed temporary write/read/delete probes without a workdir override or escalation. Project registration remained a separate step:
project/createfor the existing destination directory andthread/metadata/updateto assign its returnedprojectIdto both chats. Responses showed the intended membership and cwd. Repeating project creation with the same idempotency key was separately checked in an isolated fixture and returned the same ID.list_projectstool did not list that project at the point checked. The nativemove_thread_to_projecttool refused the legacy chats with “The task's source project could not be safely determined.”We did not test restarting between API assignment and the legacy-catalog update, so this does not show that the catalog update was necessary or that restart alone would have failed. We also have not established a contract requiring app-server-created projects to appear automatically in Desktop.
This is an observed interoperability gap, not a proven shared root cause or a supported workaround. A supported recovery flow should handle legacy unassigned chats and verify cwd, effective permissions, project registration and Desktop membership together while preserving history.