What version of Codex CLI is running?
0.133.0
What subscription do you have?
ProLite
Which model were you using?
No response
What platform is your computer?
No response
What terminal emulator and version are you using (if applicable)?
No response
Codex doctor report
What issue are you seeing?
When using a separately started app-server and connecting the TUI with --remote unix://, resuming an existing session from a different current working directory shows the cwd selection prompt, but the selected cwd is not applied to the actual resumed session.
The TUI prompt appears correctly:
Choose working directory to resume this session
Session = latest cwd recorded in the resumed session
Current = your current working directory
› 1. Use session directory (/path/to/original/project)
2. Use current directory (/path/to/new/project)
Press enter to continue
If I select the current directory, the TUI enters the resumed session, but the running session still uses the old cwd from the already-loaded app-server thread. This affects cwd-dependent behavior such as shell commands, project-local configuration, and project-local skill loading.
What steps can reproduce the bug?
Use an isolated CODEX_HOME so the test does not depend on an existing local install:
export CODEX_HOME=/tmp/codex-upstream-home
Start a separate app-server:
npx -y @openai/codex@0.133.0 app-server daemon start
Create or open a session from directory A:
cd /path/to/project-a
npx -y @openai/codex@0.133.0 --remote unix://
Exit the TUI, leaving the app-server daemon running.
Then resume the same session from directory B:
cd /path/to/project-b
npx -y @openai/codex@0.133.0 --remote unix:// resume <thread-id>
When the prompt asks which working directory to use, select the current directory, directory B.
The TUI opens the session, but the resumed session still behaves as if its cwd is directory A.
You can also check the running daemon version with:
npx -y @openai/codex@0.133.0 app-server daemon version
And stop it after testing with:
npx -y @openai/codex@0.133.0 app-server daemon stop
What is the expected behavior?
If the user selects the current directory in the resume prompt, the resumed session should actually run with that selected cwd.
When the app-server already has an idle cached thread loaded for the session, and the requested resume cwd differs from the cached thread cwd, app-server should not silently reuse the old loaded thread. It should either unload/recreate the idle cached thread before completing the same resume request, or otherwise ensure the resumed thread's real execution cwd matches the user's selection.
Additional information
This is reproducible with the upstream npm package using a separate app-server and TUI connected through --remote unix://; it does not require local patches.
My current workaround is to force the app-server not to reuse the stale loaded thread when the requested resume cwd differs. In my local build, I unload the idle cached thread before completing the resume with the newly selected cwd, while preserving the background app-server lifetime for normal same-cwd resumes.
What version of Codex CLI is running?
0.133.0
What subscription do you have?
ProLite
Which model were you using?
No response
What platform is your computer?
No response
What terminal emulator and version are you using (if applicable)?
No response
Codex doctor report
What issue are you seeing?
When using a separately started app-server and connecting the TUI with
--remote unix://, resuming an existing session from a different current working directory shows the cwd selection prompt, but the selected cwd is not applied to the actual resumed session.The TUI prompt appears correctly:
If I select the current directory, the TUI enters the resumed session, but the running session still uses the old cwd from the already-loaded app-server thread. This affects cwd-dependent behavior such as shell commands, project-local configuration, and project-local skill loading.
What steps can reproduce the bug?
Use an isolated
CODEX_HOMEso the test does not depend on an existing local install:export CODEX_HOME=/tmp/codex-upstream-homeStart a separate app-server:
Create or open a session from directory A:
cd /path/to/project-a npx -y @openai/codex@0.133.0 --remote unix://Exit the TUI, leaving the app-server daemon running.
Then resume the same session from directory B:
When the prompt asks which working directory to use, select the current directory, directory B.
The TUI opens the session, but the resumed session still behaves as if its cwd is directory A.
You can also check the running daemon version with:
And stop it after testing with:
What is the expected behavior?
If the user selects the current directory in the resume prompt, the resumed session should actually run with that selected cwd.
When the app-server already has an idle cached thread loaded for the session, and the requested resume cwd differs from the cached thread cwd, app-server should not silently reuse the old loaded thread. It should either unload/recreate the idle cached thread before completing the same resume request, or otherwise ensure the resumed thread's real execution cwd matches the user's selection.
Additional information
This is reproducible with the upstream npm package using a separate app-server and TUI connected through
--remote unix://; it does not require local patches.My current workaround is to force the app-server not to reuse the stale loaded thread when the requested resume cwd differs. In my local build, I unload the idle cached thread before completing the resume with the newly selected cwd, while preserving the background app-server lifetime for normal same-cwd resumes.