[BUG] Tool guidance to use absolute path is very counterproductive with `CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR=1`
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
I understand that tool descriptions instruct Claude to use absolute paths. This is very counterproductive, particularly when CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR=1. In complex environments Claude often gets confused w.r.t what it should be doing and which absolute path it should use.
Last week I had setup a git worktree in a subdir of main worktree (now I know better) - in a session inside the subdir worktree, Opus 4.5 kept trying to work on the main one instead, and blamed the tool "absolute path" instructions on its mistakes.
Just now:
● This log seems to be from a different worktree/repo ([...]/worktrees/dev/). Let me check if there's a more recent log,
and look at the make_test script to understand the path resolution.
● Searched for 2 patterns, read 3 files (ctrl+o to expand)
⎿ Interrupted · What should Claude do instead?
❯ what are you taking about grep "Entering directory"!!!
● Searched for 1 pattern (ctrl+o to expand)
● This log is from a different environment entirely — [...]/worktrees/dev/, not the current worktree. This is a stale log
file. The ../../test_log.txt path resolves to /home/[...]/test_log.txt which is shared across all worktrees.
Could you re-run the command, or point me to the correct log file? This one predates our changes.
❯ What is your cwd???
● Bash(pwd)
⎿ /home/[...]/worktrees/maintenance/devcontainer_full_tests
● /home/[...]/worktrees/maintenance/devcontainer_full_tests — so ../../test_log.txt is
/home/[...]/test_log.txt, which is the file I read. [...]
What Should Happen?
Remove "absolute path" instructions - at least when CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR=1 is set (IMHO ought to be the default!). In my last example, if it would have just passed the ../../test_log.txt to the grep/read tools, I would not be here typing in this issue report.
Error Messages/Logs
Steps to Reproduce
$ env CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR=1 claude
Claude Code v2.1.36
▐▛███▜▌ Opus 4.6 · Claude Max
▝▜█████▛▘ ~/ofrak-vscode
▘▘ ▝▝ Opus 4.6 is here · $50 free extra usage · /extra-usage to enable
❯ What tool descriptions indicate preference or requirement for using an absolute path?
● Here are the tools whose descriptions indicate a preference or requirement for absolute paths:
1. Read — file_path: "The file_path parameter must be an absolute path, not a relative path"
2. Edit — file_path: "The absolute path to the file to modify"
3. Write — file_path: "The absolute path to the file to write (must be absolute, not relative)"
4. NotebookEdit — notebook_path: "The notebook_path parameter must be an absolute path, not a relative path."
5. Bash — (preference, not hard requirement): "Try to maintain your current working directory throughout the session by using
absolute paths and avoiding usage of cd."
So Read, Write, and NotebookEdit explicitly require absolute paths with strong wording. Edit labels its parameter as "absolute
path" but doesn't include a "must be" warning. Bash expresses a preference for absolute paths as a way to maintain a stable working
directory. Glob and Grep have no such requirement — their path parameters default to the current working directory if omitted.
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.36
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
VS Code integrated terminal
Additional Information
Just noticed when preparing the current report - but obviously the Bash tool instructions also ought to be different with CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR=1 is enabled
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗