claude-code - 💡(How to fix) Fix [Feature Request] Add trusted framework paths for autonomous agent permission bypass [1 participants]

Bug Description Agent permission model needs a "trusted framework paths" concept for autonomous agents

Problem

Claude Code's permission system is designed around interactive human-in-the-loop sessions: when an unfamiliar command or path appears, the user sees a prompt and decides whether to allow it. That model works well for a human developer sitting at a terminal.

It works poorly for autonomous agents operating inside a framework. I'm building the-agency, a multi-agent framework where agents run unattended: polling queues, reading handoffs, running framework tools, responding to events. Most of these operations are read-only and touch a small, predictable set of paths (claude/, ~/.agency/, .claude/, usr/). They are not commands a human should be asked about — they are the framework's own internal plumbing.

What happens in practice:

• An autonomous worktree agent hits a permission prompt on ls ~/.agency/, git show HEAD -- claude/config/agency.yaml, or sqlite3 ~/.agency/iscp.db "SELECT ...".
• The agent is running unattended. There is no human at the terminal to approve the prompt.
• The agent blocks, or the prompt goes to a buffer the agent can't read, and the agent appears to hang for no reason with no visible signal.
• By the time the principal notices, minutes or hours have passed.

Adding entries to settings.json helps somewhat, but:

• Permission changes require a session restart to take effect — an autonomous agent can't restart itself in-place.
• The settings.json permission grammar is command-oriented, not path-oriented. It's hard to say "any read operation on ~/.agency/" without enumerating every verb (ls, cat, git, sqlite3, find, stat, ...).
• Brace expansion (mkdir -p {a,b,c}) is treated as a compound command even though the shell expands it to a single mkdir call. Same with cmd1 && cmd2 where both commands are individually allowed.

Steps to reproduce

1. Build an autonomous agent that polls a queue on a schedule (I use dispatch-monitor under the Claude Code Monitor tool).
2. The agent is configured to run in the background, with no human present to approve prompts.
3. The agent attempts any of: - git -C /path/to/worktree show HEAD -- some-file.md - sqlite3 ~/.agency/the-agency/iscp.db "SELECT * FROM dispatches" - ls ~/.agency/ - mkdir -p some-project/{docs,src,tests} (brace expansion)
4. Observe: Claude Code raises a permission prompt that the agent cannot see, acknowledge, or act on.

Expected behavior

One of the following options (listed in preference order):

Option 1: Trusted framework paths

{ "permissions": { "trustedFrameworkPaths": [ "~/.agency/", "./claude/", "./.claude/" ] } }

Any read-only operation on these paths is auto-approved. Writes still gated. This narrowly expands read-trust without opening write-trust.

Option 2: Agent mode

A session-level flag --agent-mode that marks a session as autonomous. Read operations on any path under the project root are auto-approved. Write operations still gated. Permission prompts replaced with structured errors the agent can handle.

Option 3: Hot-reload permissions

Allow settings.json changes to take effect without a session restart. Current workflow forces autonomous agents to lose conversation context on every permission update.

Option 4: Better prompt visibility

If prompts must remain, expose them via a programmatic channel the agent can see (status-line API, pending-prompt tool call). The current model where prompts go to a terminal buffer the agent can't read is the worst case.

Option 5 (narrower but independently valuable): Fix brace expansion parsing

Brace expansion is a single command — the shell expands it before execution. The permission parser should recognize this and match against the mkdir allowlist normally instead of treating it as multiple commands. Same for compound command patterns where both components are individually allowed.

Why this matters

For the framework-building use case:

• the-agency is an open-core framework whose premise is that agents operate with increasing autonomy inside a well-defined framework scope.
• Every permission friction breaks the framework's promise. "The captain handles this for you" becomes "the captain is frozen on a permission prompt you can't see."
• We've built elaborate workarounds: dispatch-monitor, block-raw-tools hook, run-in tool, complex settings.json grammar — all of which exist to route around the permission model.

For the autonomous agent trend broadly:

• Claude Code's developer audience is increasingly using it for agent-backed workflows.

Feedback ID: b3bb3ef6-f9ad-4400-8c20-b25f69000d8a Note: Content was truncated.