Feature Request: Ability to change working directory during Claude session

why not start the claude session from a parent directory which will contain both your project repo's ? im assuming your request was not developed so claude wouldn't go rogue and make changes outside its working directory when its least expected to.

why not start the claude session from a parent directory which will contain both your project repo's ? im assuming your request was not developed so claude wouldn't go rogue and make changes outside its working directory when its least expected to.

I'm working on a compiler that has to live in ~/dev/projects
Sometime I want to go into a real app using my compiler.
The apps I develop are not in ~/dev/projects.

Sometime I'm working on something and I was not really aware it could benefit another project for example.

It would be a great convenience to be able to run /cd as a claude command and change the working directory. Its fine if another permission screen comes up. I use claude code for a lot of none pwd related tasks and so when I do require a specific pwd it would be great to have this convenience.

actually what i recently needed is -

i moved my current project to another directory and was no longer able to continue the session because it seems sessions operate on specific paths.

is there a way to link a session i had to the new directory

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Commenting here to keep the issue open.

bumping this issue; and jfyi, the moving steps of this script works pretty well: https://github.com/skydiver/claude-code-project-mover

bump, would be a nice feature to avoid restarting session to move to another dir

Ditto, I need instance isolation in multi project, multi Claude sessions running on the same project or different projects, and the hooks don't talk nice to the Cli tty, particularly in TMUX environments or other multiplexing scenarios. This is for human in the loop orchestration.

Containers work but add even more complexity and should be left for autonomous work

Bumping this issue. This feature would be useful for working across inter-repo api boundaries and for working on internal dependencies that live in a different repo.

Bump! I was close to write the exact same feature request!

Use case: Zoom in / Zoom out during brainstorming and design sessions

When working on a multi-module project, the thinking process naturally moves between scopes:

1. Start at the project root — brainstorm the overall architecture
2. Zoom into a specific module (e.g., archimdb/) — drill down into its design
3. Zoom further into a subpackage (e.g., src/query/) — refine implementation details
4. Zoom back out to the project root — verify cross-module consistency

Currently, the working directory is fixed at session start, which means:

• Subdirectory-specific CLAUDE.md instructions don't activate as the "root" context
• File exploration picks up noise from unrelated modules
• The cognitive scope of the session doesn't match the thinking scope

A /cd command would let the session's context naturally follow the user's train of thought — like zooming in and out on a map. This is especially valuable for iterative design work where you're constantly moving between high-level and low-level thinking.

Our workaround + why native support matters

We hit this daily in our multi-repo ecosystem (30+ projects). Our workaround is an epistemic state manager
(https://github.com/Nubaeon/empirica) that handles project-switching at the context layer:

empirica project-switch other-project # switches context, loads state, attaches session
# ... work in other project ...
empirica project-switch original-project # context preserved from before the switch

This handles the state/context side — goals, findings, decisions, calibration data all persist and transfer. But
Claude Code still thinks it's in the original directory, so we're doing path gymnastics (cd /path/to/other && ...)
for every shell command.

What we really need is a /cd or /project command that:

1. Changes the working directory
2. Reloads the relevant CLAUDE.md for the new project
3. Preserves conversation history (the whole point)

The zoom-in/zoom-out pattern @y1o1 describes is exactly right — brainstorming naturally crosses project boundaries.
Today we manage the cognitive context ourselves; it'd be much cleaner if Claude Code managed the working directory
natively.

Another use case is copying useful context to new projects:
Today I started work on a new project, related to but distinct from the previous project I was working on with Claude. A lot of the information from sessions working on the previous project is still useful. I would like to be able to branch my old session and move the branch to a new directory to preserve context from the previous project.

While native directory switching isn't supported, you can simulate it with a PreToolUse hook that auto-prefixes commands with cd:
1. Create a "virtual CWD" file:

echo "/path/to/your/project" > ~/.claude/virtual-cwd

2. Add a PreToolUse hook that injects the CWD:

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "INPUT=$(cat); VCWD=$(cat ~/.claude/virtual-cwd 2>/dev/null); [ -z \"$VCWD\" ] && exit 0; CMD=$(echo \"$INPUT\" | jq -r '.tool_input.command // empty'); if [ -n \"$CMD\" ] && ! echo \"$CMD\" | grep -q \^cd

Worth noting: PreToolUse hooks can only allow or deny tool calls — they cannot modify tool_input. So the cd injection pattern described above won't actually work in practice. The hook would need to be a command type that outputs modified JSON, but the PreToolUse protocol doesn't support input rewriting, only allow/deny decisions.

For CWD-dependent workflows, we use the project path from our transaction state files as the authoritative source (not CWD), since CWD can be reset unexpectedly by Claude Code during long sessions. The transaction file persists across compactions and is instance-aware.

Separately — if hooks could receive context_window data in their input (currently only the statusline script gets it), that would solve a related problem. We had to build a two-step workaround where the statusline writes context usage to a state file and hooks read from that file. Having context_window in hook inputs directly would make context-aware hooks much simpler.

Another use case for this is git worktrees - if I want to work on multiple things at once on the same repository I now must switch fully to the new worktree folder, completely losing all of my sessions and memory about the project. Not ideal.

Lightweight workaround proposal: expose /clear as a tool so skills can implement scope switching

The core pain point in this issue is that Claude Code's context is locked to one working directory. A full /cd implementation would be ideal, but here's a much lighter alternative that could unlock community solutions:

If /clear were callable from skills/tools, we could build a /scope skill that:

1. Summarizes the current conversation → saves to memory
2. Calls /clear to reset context
3. Reads the target directory's CLAUDE.md to load new scope rules
4. Restores the previous summary from memory

/scope frontend    # clear → load frontend/CLAUDE.md → resume with context from memory
/scope backend     # clear → load backend/CLAUDE.md → same thing

Why this is useful even without "scope out":

• Scope in is what matters most — "I want to focus on this subdirectory now"
• To switch scope, just /scope again (clear + reload = implicit scope out)
• Memory persists across clears, so conversation context isn't truly lost

Why this is a smaller ask than /cd:

• /clear already exists as a CLI command — just needs to be exposed as a tool
• No need to change working directory mechanics, file resolution, or session management
• The community can iterate on scope management patterns via skills, rather than waiting for a built-in solution

Would love to hear if there's a technical reason /clear can't be tool-callable.

Another use case for this is git worktrees - if I want to work on multiple things at once on the same repository I now must switch fully to the new worktree folder, completely losing all of my sessions and memory about the project. Not ideal.

yes! I second the worktrees usecase. with multiple session in progress its almost a given that worktrees will be needed and sometimes a session that started at a root project folder would benefit a lot from moving into the worktree directory. for example to open an IDE like vscode directly in that worktree repo, or simply so that the agent can waste less tokens adding some huge cd projects/blahblah/.worktrees/currentbranch & to each and every action.

Funnily, just yesterday claude itself started 4 subagents in their own worktrees to work on 4 parallel tasks. Outcome? 3/4 of them did all the work using cd /repo/root && ... 🙃 fighting each others changes for most of the time, resetting, etc.

plz it can't be that hard can it?

Astounding that this still isn't implemented.

plz it can't be that hard can it?

IMHO quite hard - Claude has a ton of things tied to the directory it's in - sessions logs, memory files, permissions, settings, CLAUDE.md, etc, etc. Each of those requires a design choice, with careful consideration of a crazy number of corner cases :(

Proposed Solution

A built-in /cd slash command would:

• re-resolve the CLAUDE.md hierarchy (per-project hierarchical CLAUDE.md

files, as documented for hierarchical project setups)

• switch the memory scope to the new project's memory directory
• reload project-scoped skills, hooks, and settings
• keep the conversation history intact, so context built up so far is

not lost (or at minimum offer a flag to clear or preserve it)

Use Case Example

Use case: a user with many parallel projects (health, finance, multiple
client engagements) sometimes pivots mid-session — e.g. "by the way,
let's quickly check something in project X and come back". Today this
pivot is heavyweight; with /cd it becomes a one-liner.

I use this skill:

---
name: cd
description: Change working directory.
---

# /cd

Run `cd <path>` in Bash. Use the path exactly as given — do not
resolve, expand, or prepend any base directory. If the user passes a
relative path, run `cd` with that relative path from the current
working directory.

This should be made a built-in feature.

This skill USED to reload CLAUDE.md allowing me to cd around into different repository checkouts. This undocumented feature regressed, leading me to search what happened and ultimately leading me to finding this issue. Sigh.

> plz it can't be that hard can it? IMHO quite hard - Claude has a _ton_ of things tied to the directory it's in - sessions logs, memory files, permissions, settings, CLAUDE.md, etc, etc. Each of those requires a design choice, with careful consideration of a crazy number of corner cases :(

It would be difficult to imagine a simpler problem in software engineering than changing the working directory.

The os.chdir() syscall is trivial. What makes it hard in Claude Code is that every consumer of CWD becomes a state-machine question the moment you change it mid-session.

We maintain a plugin (Empirica) that tracks per-project epistemic state across Claude Code sessions. CWD handling is our largest single category of bugs by a wide margin. A few representative ones:

• Compact rotation re-spawns the conversation and often lands in a different CWD than the original. Anything keyed by CWD now reads from the wrong project silently. We solved this with an instance-id key (TMUX_PANE / WINDOWID / TERM_SESSION_ID) plus explicit transaction files — 6+ iterations to get right.

• Subdirectory pollution we shipped a fix for today: cd ~/repo/docs/ && empirica project-bootstrap was creating a stray .empirica/cache/ inside docs/. Default fell back to os.getcwd(). Two-line cause, but the failure mode was "unable to open database file" several CLI invocations later when a different resolver walked up, found the cache-only stray, and tried to open a sessions.db that didn't exist.

• Multiple panes, same project: two tmux panes both in ~/repo/ need to be the same project for CWD-based tooling but different instances for per-pane state. CWD alone can't disambiguate.

So one-line syscall, weeks of design work for every consumer downstream. Auto-memory, session files, hook context, settings resolution, gitStatus injection, plugin-internal resolvers — each needs an explicit decision on what "current project" means and how it survives the change. "Just trust the new CWD" is usually wrong because the previous CWD often had in-flight state (open transactions, unsaved hooks, partial writes) that needs an explicit handoff rather than abandonment. Not as trivial as it first seems.

The os.chdir() syscall is trivial. What makes it hard in Claude Code is that every consumer of CWD becomes a state-machine question the moment you change it mid-session.

I suggest to use dependency injection of a trait/interface, and a linter to prevent std::cwd usage or whatever language you're using. Encode the state machine lifecycle directly. You can then mock cwd state machine and test any component.

Rust enums make this trivial but the same thing can be achieved in any language.

We're talking about having concurrency protection over a pretty simple operation. Large apps are large. cd is cd. A large app should not struggle with cd because it is large. it should struggle with problems from the 21st century, or at least post 2010s.

The same pattern works for time, logging, metrics, tasks, etc. Codify your pattern and write linters so the interns don't read std::env, etc. three hours after process startup.

Cheers. All fun.

@Nubaeon

Ditto, I need instance isolation in multi project, multi Claude sessions running on the same project or different projects, and the hooks don't talk nice to the Cli tty, particularly in TMUX environments or other multiplexing scenarios.

EXACTLY this. I have exactly(?) the same need, specifically using Git worktrees where I need to stop Claude Code from ready and writing to the root when I launch Claude prior to having created a worktree. I need this for a project I am building that integrates with Claude Code.

In my opinion, the addition of agent view made the need for this feature even more urgent.

If I'm working in parallel with multiple agents, I don't want to manage multiple tabs each with sets of agents organized by working directory. That's a mess. I want to just be able to spawn another agent from agent view and say "OK, for this agent, this is your CWD." Then I can have all my agents together and jump back and forth between them.

The particulars of the implementation (even though they're important) should be hidden for the convenience of the user and the clarity of the UI.

I can confirm that this is a problem with the agent view. It's often using the wrong cwd and then getting confused again and again. Even more of an issue as I have the same repo cloned multiple times and it then starts editing the wrong one.

A concrete agentic-work data point in support of this, from a long multi-hour Rust build/test session (Claude Code driving cargo across a ~100-crate workspace):

The cwd non-persistence bites hardest with background Bash commands. A foreground cd subdir && cargo test works fine, but the same command launched as a background task starts from the default directory — so cargo test exits immediately with could not find Cargo.toml before running a single test. The failure mode is silent in the worst way: you get a 2-line output (the error + a non-zero exit) that's easily mistaken for "tests ran, something's off" rather than "the command never executed." In my session I twice misattributed an empty, never-ran test sweep as a real result because of this — only catching it by md5-summing the log file and noticing it was 2 lines long.

The interactive cwd also silently resets between calls over a long session: a cd that "stuck" earlier is gone several calls later, with no signal that it happened.

Net effect for serious agentic work: every Bash invocation has to be defensively prefixed with cd /abs/path &&, foreground and background alike, and you can't trust any relative path or any "I changed directory earlier" assumption. Beyond the token cost, it's a genuine correctness hazard — a wrong-cwd command that happens to succeed (e.g. writing a file to the wrong place, or running a tool against the wrong tree) is far more dangerous than one that errors out loudly.

A persistent shell session — or at minimum, background commands inheriting the interactive cwd plus an explicit signal when cwd resets — would eliminate a whole class of these errors.

I end up having to ask my agents to run all commands with cd ../repo &&, as it's very normal for a workflow to start in one repo and ending up touching some other, this is so needed!!

/cd has been added as a command https://code.claude.com/docs/en/commands . This issue should now be closed @CharlonTank ?

/cd has been added as a command https://code.claude.com/docs/en/commands . This issue should now be closed @CharlonTank ?

It looks like this was implemented only in the CLI. Is a similar approach planned for Claude Code Desktop too?

What I am missing is, to start a new session on a specific worktree, without having to navigate to the specific folder of the worktree, which would count as an extra project too. So a simple worktree selection for new sessions, or for switching would really be helpful

Thank you @dkorunda-tp 🙏
@daberni i have no clue