[BUG] --agent mode ignores explicit permissions.allow rules for built-in read-only commands
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 Claude Code is launched with --agent <name>, explicit permissions.allow rules for commands on the built-in read-only list (ls, cat, head, tail, etc.) are silently ignored — the agent prompts for permission anyway. Rules for commands NOT on the built-in list (e.g., Bash(jq *)) work as expected.
In --agent mode:
- The built-in read-only auto-allowlist appears to be suppressed (so
ls/cataren't auto-approved as they would be in a normal session). - Explicit
permissions.allowrules for those same commands are ALSO ignored, even though/permissionslists them as active. - Explicit rules for commands not on the built-in list DO work normally.
The combination means there is no way to allowlist ls / cat / head / tail / etc. for an agent session: the built-in path is off, and the user-allowlist path appears to no-op for these specific command names. Every basic read-only Bash call prompts, with no documented way to allowlist them.
May be related to #58645 (agent frontmatter allowedTools/disallowedTools ignored for plugin agents), though that issue is about a different permission mechanism (frontmatter, plugin-only) while this one is about permissions.allow from settings.json and reproduces with a local agent too.
What Should Happen?
Per the docs, either:
- Built-in read-only commands run without prompting in every mode (then
ls/catshould not prompt), OR - Explicit
permissions.allowrules listed in/permissionsare honored (thenBash(ls *)/Bash(cat *)should match and not prompt).
Either way, ls /tmp and cat /etc/hostname should not trigger a prompt.
Error Messages/Logs
Steps to Reproduce
Preconditions: no project .claude/settings.json, no settings.local.json anywhere on disk. Session must be a fresh start (not resumed) so settings are loaded.
- Create a minimal user-defined agent at
~/.claude/agents/ops-agent.md:
```markdown
---
name: ops-agent
description: Minimal repro agent
---
You are a helpful assistant.
``tools:` field, no permissions block, no deny list.)
(Frontmatter has no
- In
~/.claude/settings.json, add topermissions.allow:
``json``
"Bash(ls *)",
"Bash(cat *)",
"Bash(jq *)"
(the last entry is a stand-in for any command not on the built-in read-only list)
- Launch a fresh session with the agent:
````
claude --agent ops-agent
- In the agent session, run
/permissionsand confirmBash(ls *),Bash(cat *),Bash(jq *)are all listed as active.
- Have the agent run each of:
jq --help→ no prompt (expected)ls /tmp→ prompts (unexpected)cat /etc/hostname→ prompts (unexpected)
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.138 (Claude Code)
Platform
AWS Bedrock
Operating System
macOS
Terminal/Shell
iTerm2
Additional Information
_No response_
4 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Thanks for the heads-up. I looked at all three suggested duplicates. None are exact matches, though they're closely related:
permissions.allow), but it's filed for skills / dispatched subagents, not--agentmode.Per the binary's own schema,
--agentruns the agent as the main session, not as a subagent ("Auto-submitted first message when this agent runs as the main session (via--agentorsettings). Not read when spawned as a subagent."), so they're separate code paths.
Read(...)rules in subagents, not Bash.I suspect all four share a root cause around how non-default agent contexts resolve
permissions.allow, but the trigger surfaces are different. Happy to close this as a duplicate if amaintainer confirms the underlying mechanism is identical to one of the others. Until then, leaving open since
--agentmode is the only one of the four where the agent is the primarysession, and that path isn't covered by the existing reports.
Cross-referencing #18950 since the symptom on Bash built-in read-only commands is the same.
Closing — original framing was a misdiagnosis on my part.
The prompts I attributed to
--agentmode were actually the standard Bash path-scope check firing on paths outside the session cwd (/tmp,/etc/hostname,~/.claude/memory/). Same prompts happen in normal sessions; they're not agent-specific.Adding the relevant paths to
permissions.additionalDirectoriesin~/.claude/settings.json(per the docs at https://code.claude.com/docs/en/permissions#working-directories) removes the prompts for reads while leaving writes gated by the current permission mode — which is the actual desired behavior.Verified working in both normal and
--agentsessions.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.