/cwd command to switch working directory without restarting session

Open 💬 10 comments Opened Feb 21, 2026 by ignatremizov
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

CLI (TUI) custom fork off of 0.104.0

What feature would you like to see?

Add a /cwd slash command to change the working directory inside the current TUI session, with a policy-selection step in the same flow.

Current workflow is frustrating:

  1. Exit TUI
  2. cd into another repo/worktree
  3. codex resume ...
  4. Re-approve sandbox/policy for that directory

This is especially painful when iterating on many sibling forks. I want Codex to keep autonomous execution within the selected repo, but I do not want to grant blanket access to the parent directory just to avoid repeated approvals.

Proposed UX:

  • /cwd <path> to switch current working directory
  • /cwd with no args opens a picker/input modal
  • In the same flow, prompt for policy handling for the target directory:
  • apply target directory defaults (trust/project policy)
  • or keep current runtime policy override
  • Show a short confirmation line in transcript (new cwd + effective approval/sandbox policy)

Additional information

Related but not equivalent: /add-dir (#11747) expands access roots; it does not switch active cwd and policy context.

Short implementation sketch:

  1. Wire command + dispatch
  • codex-rs/tui/src/slash_command.rs: add SlashCommand::Cwd with description and inline args support.
  • codex-rs/tui/src/chatwidget.rs: dispatch /cwd and /cwd <path> via a new app event.
  1. Add app-level event and handler
  • codex-rs/tui/src/app_event.rs: add AppEvent::ChangeCwd { path: Option<String> }.
  • codex-rs/tui/src/app.rs: handle ChangeCwd by resolving/validating path, then rebuilding config with existing rebuild_config_for_cwd(...).
  1. Apply cwd + policy atomically
  • Reuse rebuilt config’s derived approval/sandbox defaults for target cwd.
  • Send Op::OverrideTurnContext { cwd: Some(...), approval_policy: Some(...), sandbox_policy: Some(...) } so core session state updates without restart.
  • Update in-memory TUI state (self.config, file-search root via file_search.update_search_dir(...), and chat widget config copy) so UI and behavior stay consistent.
  1. Prompt UI and tests
  • Reuse/extend codex-rs/tui/src/cwd_prompt.rs patterns for selection/confirmation.
  • Add tests in codex-rs/tui/src/chatwidget/tests.rs and codex-rs/tui/src/app.rs for command dispatch, path validation, and policy-application behavior.

Status after #38894

#38894 / commit ed32158e90ef872c5eef96baf2f14feac70aee6e is a good direction and solves the core pain point: /cd <path> can switch an idle local TUI conversation to another working directory while preserving history and reloading the destination project context.

The command naming is not considered a gap. /cd is the conventional user-facing command for changing directories, while /cwd is reasonable as an alias for /pwd.

Remaining follow-up work:

  • Policy selection: add an in-flow choice between applying the destination directory's defaults and retaining the current runtime policy override. The implementation currently applies compatible overrides automatically and rejects incompatible transitions.
  • Directory-switching restrictions: revisit the deliberately conservative blanket restrictions. Some currently rejected transitions may be supportable where the relevant state can be transferred safely.
  • Bare command UX: open a directory picker or input prompt for bare /cd instead of always selecting ~.
  • Fork versus move semantics: the current implementation forks and replaces the active thread. Some workflows instead need to move the existing thread to the new directory without changing its identity, so this should be an explicit choice or preserve the original thread when safe.
  • Confirmation: include the resulting approval and sandbox policy alongside the new path in the transcript confirmation.

The merged implementation establishes the right foundation, while these policy-selection and transition-semantics gaps remain in scope for this issue.

View original on GitHub ↗

10 Comments

github-actions[bot] contributor · 6 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #12232
  • #11747

Powered by Codex Action

Astro-Han · 5 months ago

I want to add one clarification here: for me this is not just a generic directory-switching request.

The most important case is switching the active session into another existing git worktree without leaving Codex, manually cd-ing, and restarting/resuming.

So if this issue becomes the main tracking thread for in-session cwd switching, I would strongly consider existing worktree navigation to be a core use case, not just an edge case.

backnotprop · 4 months ago

Need this.

justinTM · 4 months ago

desktop app frequently gets stuck in its workdir. when the model returns filepaths different from what appears in terminal or file tree, you have no option in the app to rectify this mismatch.

moddyfire · 4 months ago
I want to add one clarification here: for me this is not just a generic directory-switching request. The most important case is switching the active session into another existing git worktree without leaving Codex, manually cd-ing, and restarting/resuming. So if this issue becomes the main tracking thread for in-session cwd switching, I would strongly consider existing worktree navigation to be a core use case, not just an edge case.

This doesn't even work for me. If I close, cd, codex --resume it doesn't have permissions for the new directory. Or maybe it was bug.

backnotprop · 2 months ago

Major paper cut right here.

backnotprop · 2 months ago

Oh, I already commented above April 14th and got 14 upvotes. I forgot about that and just continued to run into it. came searching for a solution.

thewh1teagle · 1 month ago

Meanwhile you can ask codex

 Get the current Codex session id from the environment and give me the exact resume command from new-folder/.
ignatremizov · 1 month ago

@thewh1teagle lol what a waste of tokens. /statusline and enable session-id, or get it from /status directly

cd to your path and resume from there

ignatremizov · 5 days ago

PR #38894 / commit ed32158e90ef872c5eef96baf2f14feac70aee6e is a good direction and solves the core pain point: /cd <path> can now switch an idle local TUI conversation to another working directory while preserving its history and reloading the destination project context.

The command naming looks right to me. /cd is the conventional user-facing command for changing directories, while advanced users are likely to understand /cwd as an alias for /pwd anyway. I would not treat that naming difference as a gap.

There are still a few parts of the requested flow worth tracking:

  • Policy selection: there is no in-flow choice between applying the destination directory's defaults and retaining the current runtime policy override. The implementation currently applies compatible overrides automatically and rejects incompatible transitions.
  • Directory-switching restrictions: the initial implementation is deliberately conservative. Some blanket restrictions may be unnecessary where the relevant state can be transferred safely, and should be revisited rather than becoming permanent limitations.
  • Bare command UX: /cd without a path currently selects ~; it should offer a directory picker or input prompt.
  • Fork versus move semantics: the current implementation forks and replaces the active thread. That is useful when a fork is desired, but some workflows need to move the existing thread to the new directory without changing its identity. The user should have an explicit choice, or the operation should otherwise preserve the original thread when safe.
  • Confirmation: the transcript confirms the new path but does not show the resulting approval and sandbox policy.

So this establishes the right foundation and addresses the main workflow, but the policy-selection and transition semantics from this issue remain useful follow-up work.