[Feature Request] ability to change Working Directory mid-session
Hi, it would be very useful if we could change the working directory mid-session.
When I use claude code, I usually need to work across multiple repos, and those repos are interconnected closely so sharing the same context helps.
For example, I may ask it to do some code change in repo A (which is a library), then I want it to be able to cd to repo B (which is an application) to update the code to use the new feature in repo A.
This is impossible to do now, as we get
Error: ERROR: cd to '...' was blocked. For security, Claude Code may only change directories to child directories of the original working directory (...) for this session.
Even if I manually use bash mode and
! cd ...(new directory)
I get
Shell cwd was reset to ...(original working directory)
So it would be great if we can explicitly change the working directory.
Thanks.
I'm in monorepo(Turborepo) and sometimes i need this feaature.
It's good to have cd boundary so that Claude can safely cd to the ancestor directories until the boundary blocks.
#1588
claude can't cd .. from where you opened claude
BUT claude CAN cd foo and then cd .. to where you started.
> cd onto Developer/foo
⏺ I'll navigate to the Developer/minerlab directory.
⏺ Bash(cd ~/Developer/foo && pwd)
⎿ Error: ERROR: cd to '/Users/adrian/~/Developer/foo' was blocked. For security, Claude Code may only change directories to child directories of the original working directory
(/Users/adrian) for this session.
⏺ Let me try with the correct path:
⏺ Bash(cd /Users/adrian/Developer/foo && pwd)
⎿ /Users/adrian/Developer/foo
⏺ Successfully navigated to /Users/adrian/Developer/foo.
> now cd ..
⏺ Bash(cd .. && pwd)
⎿ /Users/adrian/Developer
> now cd ..
⏺ Bash(cd .. && pwd)
⎿ /Users/adrian
So while not ideal, you may start all your sessions from ~ and ask to cd to where you wanna work on while retaining the ability to move from ~/*
You still miss things like /tmp which was my original request https://github.com/anthropics/claude-code/issues/1588
I naturally tried starting session at / but it didn't work, I could not navigate anywhere.
cwd: /
...
> cd tmp
⏺ I'll change to the tmp directory for you.
⏺ Bash(cd /tmp && pwd)
⎿ /tmp
⎿ Shell cwd was reset to /
> no just `cd tmp` not `/tmp`
⏺ I'll change to the tmp directory (not /tmp).
⏺ Bash(cd tmp && pwd)
⎿ /tmp
⎿ Shell cwd was reset to /
Okay, thanks for the info @adriangalilea
I understand you can indeed do this to mitigate this problem.
However, I also think it would be nice if claude code can offer a feature to allow user to explicitly change the working dir, such as using /cd command. I don't see any obvious reason why such a feature can't be implemented
I don't see any obvious reason why such a feature can't be implemented
Security, this systems are becoming too smart, they can run things behind your back if they go rogue/prompt-injected/hallucinate. Guardrails are mandatory now, but I do agree granular control over these is necessary.
Check the other issue I linked before, it is also a feature request similar to yours.
Just wanted to share a temporary solution with everyone to make the situation less annoying in the meantime.
Yeah, I understand this is a guardrail and a security feature.
What I'm suggesting is, user can intentionally and explicitly run a /cd command (just like they can run /compact) to change the working directory. This new command will be very useful, and it will be un-injectable (since the only way to trigger this behaviour is if the user's input explicitly starts with /cd, user input is not injectable as it only comes directly from the user).
Can I add to this suggestion: I came looking for the ability to change working dir to a subdirectory of the project.
Scenario:
- Using git worktrees to isolate agent changes
- It's convenient to create a custom slash command
/treeto create a worktree for you and cd into it - But whenever Claude makes changes from within the worktree, it goes out of it's way to change the files in the root rather than the worktree it just
cd'd into - e.g.Write(../../../somefile.ts).
Seems like something in the system prompt is prompting it to use the project root rather than the dir it cd'd into.
Hi all, you can now add additional working directories to an existing session. Claude Code can read and edit files and cd to those directories just like with the original working directory.
Because the session settings are loaded from the original working directory, if you need to change the original working directory, the best way to do that is to exit Claude Code and start a new session.
Hi all, you can now add additional working directories to an existing session. Claude Code can read and edit files and cd to those directories just like with the original working directory.
This doesn’t seem to work for me,
When I add:
{
...
"permissions": {
...
"additionalDirectories": ["/tmp/", "/Users/adrian/", "~"]
}
}
To my ~/.claude/settings.json it still complains:
⏺ Bash(cd ~ && pwd)
⎿ /Users/adrian
⎿ Shell cwd was reset to /Users/adrian/Developer/
⏺ Bash(cd /Users/adrian && pwd && ls)
⎿ Error: cd to '/Users/adrian' was blocked. For security, Claude Code may only change directories to child directories of the allowed working directories
Why?
I feel like some nuance is being lost here. From my reading:
--add-dir as well as the other ways to configure it including ~/.claude/settings.json allow you to read code in that directory
BUT
the cd restriction is still in place after that. We have one monorepo where we have most of our configuration and tooling for Claude lives, and then a couple other repos we still want to be able to work on and read. It seems add-dir solves the "bring this folder into context" but not "cd into that folder and run commands"
Came here after I wanted exactly the same: to create worktrees on the fly and switch to them.
You can't change it seems, but you can add a working directory using /add-dir. Hope this helps
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.