[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_

View original on GitHub ↗

6 Comments

github-actions[bot] · 9 months ago

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.

BenjaminPrice · 8 months ago

This is still an issue. I'm currently running into the same thing.
I'm using the use-intl package and have a folder at src/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).

CervEdin · 8 months ago

CC seems to have acquired a preference for using absolute paths recently, regardless wether they need escaping or not

github-actions[bot] · 7 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

avshalomt2 · 6 months ago

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.ext will require manual approval, because we don't know what the runtime variable of $var is (and it can be ../../../../../../../etc/passwd), but in case the bash syntax ($, [, ], *) is escaped, one expects not to see the Shell expansion syntax in paths requires manual approval message.

 Bash command

   grep -n "ChangeIssueStatusButton" modules/webapp/apps/webapp/src/routes/\$tenantNonce/issues/\$issueId/\$issueInstanceId.route.tsx
   modules/webapp/apps/webapp/src/routes/\$tenantNonce/issues/-components/status/ChangeIssueEntityStatusButton.tsx
   Check how it's used in the two importing files

 Shell expansion syntax in paths requires manual approval

 Do you want to proceed?
 ❯ 1. Yes
   2. Yes, allow reading from $issueId/ from this project
   3. No

I think this should be tagged as area:permissions - this is permission check fault, not Bash tool 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/x as shell expansion syntax.

github-actions[bot] · 6 months ago

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.