Investigate: planner still prompts for pre-allowed Read/Grep/Bash in plan mode despite #145

[martin-conur]

Problem

After #145 shipped (read-only allowlist seeded into .claude/settings.json via task-init), a planner session in a real claude-notion project still triggers permission prompts for Read / Grep / Bash(find) / Bash(rg) operations during exploration. Reproduced this session dogfooding.

The Claude Code reference documentation explicitly states this should NOT happen:

"Permission prompts still apply the same as default mode."
"Modes set the baseline. Layer permission rules on top to pre-approve or block specific tools in any mode except bypassPermissions."

Source: Permission modes, Permissions.

So either:

1. Claude Code's actual behavior diverges from its documentation (upstream bug), or
2. task-force's seed entries don't match the syntax Claude Code expects (our bug), or
3. There's a layering / precedence issue between .claude/settings.json and .claude/settings.local.json, or
4. Plan-mode tool calls flow through a different permission gate (e.g., spawned subagents like Explore have their own permission contexts that don't inherit the parent's allowlist).

Evidence captured this session

User's claude-notion project has all seven of #145's seeded entries present in .claude/settings.json permissions.allow:

• Read
• Grep
• Glob
• Bash(find *)
• Bash(ls *)
• Bash(cat *)
• Bash(rg *)

User reports: "each of the read grep asked for permissions" during a task-work --plan planner session that included Explore subagent dispatch + Notion MCP calls.

Existing .claude/settings.local.json in the same project has scoped Read entries like Read(//tmp/**) and Read(//Volumes/Storage/gits/groppo-worktrees/**). Open question: does the presence of scoped Read(...) entries in local.json change how the bare Read in settings.json is interpreted?

Candidate causes (investigate, rank, eliminate)

A. Settings file not loaded from cwd

claude discovers .claude/settings.json relative to cwd. If task-work --plan launches claude from somewhere other than the project root, settings could be missed. Check lib/zellij-tab.sh aw_launch_tab — --cwd is set to the worktree, but verify the worktree contains a .claude/settings.json (it's the per-project file in the main worktree, not necessarily mirrored into each worktree).

B. Subagent permission inheritance

The captured transcript shows the planner spawning Explore subagents ("3 Explore agents finished"). Subagent tool calls may evaluate permissions in their OWN context rather than inheriting the parent's settings. If Explore subagents prompt independently, the parent's permissions.allow doesn't help.

Verify: do Explore subagents see the parent's settings? Where is this documented?

C. Bare Read vs scoped Read(...) precedence

Per docs, additive. But verify empirically by:

• Removing all scoped Read(...) entries from local.json temporarily.
• Re-running a planner session.
• Observing whether bare Read then matches all Read calls.

If prompts disappear after removing scoped entries, there's a precedence bug worth filing upstream.

D. MCP server name mismatch

The user's settings.json has mcp__notion__* entries; local.json has mcp__claude_ai_Notion__* (different server name — likely a Notion MCP installed via two different paths). If the planner is hitting claude_ai_Notion MCP calls but only notion MCP is allowlisted, those would prompt. NOT the same class as the Read/Grep issue but worth ruling out as a separate prompt source.

Suggested approach for the planner picking this up

1. Reproduce in a minimal scratch project (claude-notion or claude-gh — either should exhibit if the cause is in task-force's seed).
2. Test in this exact order:
   • Test 1: claude --permission-mode plan from project root with the post-task-reviewer: tracker-aware spec-issue cross-check (claude-jira/notion/local) (#144) #145 settings.json. Run a Read tool call. Does it prompt?
   • Test 2: Same but with --permission-mode default. Does it prompt?
   • Test 3: From a subdirectory of the project (not the root). Does it prompt?
   • Test 4: With Explore subagent: spawn an Explore agent that does a Read. Does the Explore subagent prompt?
3. Whichever combination prompts → that's the cause. File upstream issue against Claude Code if it's a docs/behavior gap, or open a follow-up issue in task-force if our seed syntax is wrong.

Files / surface

• claude-gh/bin/task-init, claude-jira/bin/task-init, claude-notion/bin/task-init, claude-local/bin/task-init — the seed entries themselves; verify syntax matches Claude Code's current expectations
• claude-*/bin/task-work — verify the claude --permission-mode plan invocation passes the correct working directory
• README's task-work --plan section — once we know the answer, document the actual interaction between plan mode and the seeded allowlist

Out of scope

• The user's .claude/settings.local.json is their personal config; don't propose changes to it as a fix.
• This issue does NOT propose changing task-reviewer: tracker-aware spec-issue cross-check (claude-jira/notion/local) (#144) #145's seed entries until we know what's actually being asked for. If it turns out Read should be Read(*), that's a follow-up fix.
• Not blocking v0.3.0 cut (Cut v0.3.0 release (gated on #218 — kiro radio) #143). File-and-forget until someone hits it again or has cycles.

Priority: P2

Quality-of-life. The user has been working around with .claude/settings.local.json additions per-project. Worth fixing for the documented task-init UX promise but not blocking release.

References

• Claude Code docs: Permission modes, Permissions
• task-reviewer: tracker-aware spec-issue cross-check (claude-jira/notion/local) (#144) #145 — original read-only allowlist seed
• This session's diagnostic: claude-notion project, post-task-reviewer: tracker-aware spec-issue cross-check (claude-jira/notion/local) (#144) #145 settings.json contained all 7 seed entries, prompts still fired