Codex chat keeps stale working directory after PC/path change

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

Version 26.602.40724 • Released 6 June 2026

What subscription do you have?

Pro plan ($200/mo) 20x more usage than Plus, GPT-5.5 Pro

What platform is your computer?

Windows 11 x64 PowerShell OSVersion output: Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

I already submitted in-app feedback for this. Feedback ID:
no-active-thread-019ea49f-bcc5-79f1-b1fe-fcc87a5ba077

Subject: Codex chat keeps stale working directory after PC/path change

Hi Codex Support,

I need help with a project/session working-directory issue.

I recently changed PCs, which changed the absolute path of one of my Codex project folders. The old path no longer exists on the new machine.

After reconnecting/opening the project from the new valid folder path, the chat still appears to retain the old missing working directory internally. I repeatedly receive this error:

Current working directory missing
This chat's working directory no longer exists

The new folder path exists and is accessible, but the chat behaves as if its working directory is still the old path. Codex can work around this only by running commands from C:\ and using full absolute paths to the new folder, but the workspace connection itself appears stale.

Expected behavior:
When I reconnect or open the project at the new folder path, the chat/session should update its working directory to the new valid path, or provide a clear way to rebind the chat to the new folder.

Actual behavior:
The chat continues reporting that the working directory no longer exists, despite the project being available at the new path.

Impact:
This caused tool/command instability and made recovery difficult. It also contributed to project config/path confusion because the assistant could not rely on the normal cwd/workspace context.

Old path:
C:\Users\keith\OneDrive - Dillam Inc\HELGLO 2021\00 VJM\Competitors\Kookaburra\Codex Kookaburra Scraper V1.0

New path:
C:\Users\KPHelmsmanGlobal\OneDrive - Dillam Inc\HELGLO 2021\00 VJM\Competitors\Kookaburra\Codex Kookaburra Scraper V1.0

Please advise whether there is a way to forcibly rebind an existing chat/project to the new folder path, or whether this is a known issue with stale workspace metadata after moving machines.

Thanks.

What steps can reproduce the bug?

Feedback ID: no-active-thread-019ea49f-bcc5-79f1-b1fe-fcc87a5ba077

Subject: Codex chat keeps stale working directory after PC/path change

Hi Codex Support,

I need help with a project/session working-directory issue.

I recently changed PCs, which changed the absolute path of one of my Codex project folders. The old path no longer exists on the new machine.

After reconnecting/opening the project from the new valid folder path, the chat still appears to retain the old missing working directory internally. I repeatedly receive this error:

Current working directory missing
This chat's working directory no longer exists

The new folder path exists and is accessible, but the chat behaves as if its working directory is still the old path. Codex can work around this only by running commands from C:\ and using full absolute paths to the new folder, but the workspace connection itself appears stale.

Expected behavior:
When I reconnect or open the project at the new folder path, the chat/session should update its working directory to the new valid path, or provide a clear way to rebind the chat to the new folder.

Actual behavior:
The chat continues reporting that the working directory no longer exists, despite the project being available at the new path.

Impact:
This caused tool/command instability and made recovery difficult. It also contributed to project config/path confusion because the assistant could not rely on the normal cwd/workspace context.

Old path:
C:\Users\keith\OneDrive - Dillam Inc\HELGLO 2021\00 VJM\Competitors\Kookaburra\Codex Kookaburra Scraper V1.0

New path:
C:\Users\KPHelmsmanGlobal\OneDrive - Dillam Inc\HELGLO 2021\00 VJM\Competitors\Kookaburra\Codex Kookaburra Scraper V1.0

Please advise whether there is a way to forcibly rebind an existing chat/project to the new folder path, or whether this is a known issue with stale workspace metadata after moving machines.

Thanks.

What is the expected behavior?

Subject: Codex chat keeps stale working directory after PC/path change

Hi Codex Support,

I need help with a project/session working-directory issue.

I recently changed PCs, which changed the absolute path of one of my Codex project folders. The old path no longer exists on the new machine.

After reconnecting/opening the project from the new valid folder path, the chat still appears to retain the old missing working directory internally. I repeatedly receive this error:

Current working directory missing
This chat's working directory no longer exists

The new folder path exists and is accessible, but the chat behaves as if its working directory is still the old path. Codex can work around this only by running commands from C:\ and using full absolute paths to the new folder, but the workspace connection itself appears stale.

Expected behavior:
When I reconnect or open the project at the new folder path, the chat/session should update its working directory to the new valid path, or provide a clear way to rebind the chat to the new folder.

Actual behavior:
The chat continues reporting that the working directory no longer exists, despite the project being available at the new path.

Impact:
This caused tool/command instability and made recovery difficult. It also contributed to project config/path confusion because the assistant could not rely on the normal cwd/workspace context.

Old path:
C:\Users\keith\OneDrive - Dillam Inc\HELGLO 2021\00 VJM\Competitors\Kookaburra\Codex Kookaburra Scraper V1.0

New path:
C:\Users\KPHelmsmanGlobal\OneDrive - Dillam Inc\HELGLO 2021\00 VJM\Competitors\Kookaburra\Codex Kookaburra Scraper V1.0

Please advise whether there is a way to forcibly rebind an existing chat/project to the new folder path, or whether this is a known issue with stale workspace metadata after moving machines.

Thanks.

Additional information

_No response_