Resuming a session from a different cwd with a separate app-server ignores the selected cwd

Resolved 💬 2 comments Opened May 23, 2026 by 92645417d9e5c763259dbebc306e3e Closed May 26, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

2 Comments

etraut-openai contributor · 3 months ago

Thanks for the detailed report. I think there may be a real bug here, but one part of the repro does not line up with current behavior.

If the TUI is launched with an explicit --remote unix://..., we classify that as a remote workspace and should skip the cwd-selection prompt entirely. So I would not expect the “Choose working directory…” prompt to appear in that exact setup.

Can you confirm whether this used an explicit --remote unix://... endpoint, or the implicit local daemon connection? If it was the implicit local daemon, I think this is a valid bug. The fix should preserve true in-flight rejoin behavior, but for an idle cached thread with a requested cwd/config mismatch, app-server should unload/recreate or otherwise retarget the thread so the actual execution cwd matches the user’s selection.

92645417d9e5c763259dbebc306e3e · 3 months ago

Thanks, I re-checked this more carefully. My earlier repro was wrong on one important detail: I accidentally copied the --remote unix:// form from a separate SSH tunnel test I was doing.

For my normal local workflow, I start the TUI with no arguments:

codex

The app-server is started separately as the local daemon:

codex app-server daemon start

So the case I am reporting is the implicit local daemon path, not an explicit --remote unix:// path.

Repro with an unpatched official install:

Install Codex using the official installer.
Start the local app-server daemon:

``sh codex app-server daemon start``

Start a TUI session with no extra arguments:

``sh codex``

Send any prompt, then exit the TUI.
Change to a different directory.
Start Codex again with no extra arguments:

``sh codex``

Resume the previous session and choose the new working directory when the cwd selection prompt appears.

Observed behavior:

The cwd selection prompt does appear, which matches the implicit local daemon behavior and confirms this is not being treated as an explicit remote workspace.
The selected cwd is not applied to the resumed session. The session still executes from the old cwd.
App-server state shows that the session still has a consumer / remains loaded, which seems consistent with the cached idle thread being reused instead of being unloaded/recreated or retargeted.

So I think your interpretation is correct: for an idle cached thread with a requested cwd mismatch, the implicit local daemon path should unload/recreate or otherwise retarget the thread so the execution cwd matches the user’s selection.