[BUG] when path requires escaping, claude uses absolute paths for bash tool calls, leading to tool reconfirmation
Status Closed — not planned
Maintainer reply None cached
Activity 6 comments · opened Dec 17, 2025 · closed Mar 16, 2026
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?
When working with files with names that must be escaped on linux: (e.g. $someRoute.tsx), claude escapes it, \$someRoute.tsx, and then doesn't realize it is local, and puts an absolute path on it's prefix.
This causes claude to force a permission request (due to the absolute path being maybe outside cluade).
What Should Happen?
Claude should check all paths and see if they can be relative (even if they are escaped) to prevent unnecessary permission requests.
The tool call should just work if it is already approved (the absolute path forces the permission).
Error Messages/Logs
Steps to Reproduce
echo 'this is a test' > ./\\$someFile
claude -p "list all files in current directory, then replace the word test with success in the someFile file using bash commands"
I'm encountering permission restrictions when trying to modify the file. The file is named `$someFile` (with a literal `$` character in the filename), which is causing some shell interpretation issues.
Here's what I found:
- **Files in directory**: Just one file named `$someFile`
- **Contents**: `this is a test`
To complete the replacement using bash, you would need to grant write permissions, or you can run this command yourself:
\`\`\`bash
sed -i '' 's/test/success/g' '$someFile'
\`\`\`
(Note the single quotes to prevent shell expansion of the `$` character in the filename.)
Would you like to grant write permissions so I can complete the replacement?
When asking it directly in interactive mode, we see that it is trying to operate on an absolute path.
⏺ Bash(sed -i '' 's/test/success/' "/Users/nthalk/local/src/iodesystems/claude-issue/\$someFile")
Bash command
sed -i '' 's/test/success/' "/Users/nthalk/local/src/iodesystems/claude-issue/\$someFile"
Replace 'test' with 'success' in file
Do you want to proceed?
❯ 1. Yes
2. Yes, and always allow access to claude-issue/ from this project
3. Type here to tell Claude what to do differently
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.0.71 (Claude Code)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
6 Comments
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.
This is still an issue. I'm currently running into the same thing.
I'm using the
use-intlpackage and have a folder atsrc/routes/{-$locale}/that is always being expanded into the full path for requests and constantly asking for permissions to access (even when choosing allow for this project).CC seems to have acquired a preference for using absolute paths recently, regardless wether they need escaping or not
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
Another similar but different case - here CC didn't use absolute path, but it still didn't auto-approve the action, despite
grep:*being approved.I would get that
grep ... path/to/$var/file.extwill require manual approval, because we don't know what the runtime variable of$varis (and it can be../../../../../../../etc/passwd), but in case the bash syntax ($, [, ], *) is escaped, one expects not to see theShell expansion syntax in paths requires manual approvalmessage.I think this should be tagged as
area:permissions- this is permission check fault, notBashtool fault.The permission tool should use Bash syntax parses (e.g. https://github.com/vorpaljs/bash-parser), as it probably already does, detect the escaped chars, and fix the false-positive detection of
path/\$nonVar/x/'path/$nonVar/x/path/'$'nonVar/xas shell expansion syntax.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.