agents: plan-mode session can escalate to edit access by delegating to the general subagent #55814

Summary

A session whose agent denies edit (e.g. the plan primary agent) can silently escalate to full write access by delegating work to the general subagent. The child session runs with its own permission policy, which allows edits, so files that the parent agent is forbidden to touch get written anyway. This broke the trust model of plan mode in a real session: the parent had every write denied, while a delegated child modified 12 tracked files.

Environment

• opencode version: v2.0.26 (opencode --version)
• OS: Microsoft Windows NT 10.0.26300.0 (X64), win32
• Terminal: Unavailable: TERM=xterm-256color, TERM_PROGRAM unset, WT_SESSION unset
• Shell: C:\WINDOWS\system32\cmd.exe (session ran PowerShell 7.6.6)
• Install/channel: release
• Active plugins: superpowers (git+https://github.com/obra/superpowers.git), @cortexkit/opencode-magic-context, @cortexkit/aft-opencode@latest, @dietrichgebert/ponytail, cc-safety-net, @bastiangx/opencode-unmoji@latest

Reproduction

1. Start a session that uses the plan primary agent, whose shipped policy denies edits except files under ~/.opencode/plan.
2. Ask the agent to implement a code change.
3. The parent agent calls the subagent tool with agent: "general" and an implementation prompt.
4. The child session applies edits and returns a success report.
5. In the same session, the parent's own write/edit calls still return permission_denied: edit is denied by this session's permission rules.

Minimal shape: any prompt that makes a read-only primary agent delegate implementation work to general.

Expected Behavior

The subagent tool should not let a child acquire permissions the parent session does not have. One of:

• The child inherits the parent session's effective permission policy (parent denies edit, child denies edit), or
• The first child write triggers an approval in the parent session, or
• The subagent tool refuses to launch, or warns before launching, a write-capable agent from a session whose agent denies edit.

At minimum the behavior should be visible to the user: the operator had no indication that delegating from plan mode would produce real file writes.

Actual Behavior

The parent session's write tool returned a hard permission denial:

write D:\Tida\psi_parse_tmp.py
permission_denied: edit is denied by this session's permission rules (not a user choice)

The general child, launched moments later with an implementation prompt, wrote 12 tracked files in the same repository without any approval prompt:

 M CONTEXT.md
 M docs/agents/article-tools.md
 M docs/agents/domain.md
 M src/components/AiSummary.astro
 M src/components/Header.astro
 M src/components/tools/MissingTeethRisk.astro
 M src/pages/mag/[...slug].astro
 M tests/a11y-css.test.ts
 M tests/advisor-guards.test.ts
 M tests/ai-summary.test.ts
 M tests/rendering.test.ts
 M tests/tool-components.test.ts

The child then reported npm run verify exiting 0, i.e. the writes were fully committed to the working tree.

No user-facing warning, prompt, or confirmation appeared for the child writes. The operator discovered the escalation only by noticing the git status.

Additional Context

This matches documented behavior, which is what makes it a trust-model gap rather than a straightforward bug:

• https://opencode.ai/v2/docs/agents: "Subagents run with fresh context in foreground or background child sessions. The parent agent's subagent permissions control which agents it may launch; the child uses its own configured permissions."
• https://opencode.ai/v2/docs/permissions: "A custom subagent uses its own permissions, not a subset of its parent's permissions." The shipped general policy only "denies questions and launching subagents", so it inherits the base { action: "*", resource: "*", effect: "allow" } rule for edit.

So a plan session is read-only only until it delegates. Since delegation to general is the primary multi-step workflow, the practical effect is that plan mode can be bypassed by any task phrased as "delegate this to a subagent".

Two concrete requests:

1. Document the escalation in the agents/permissions guides, since the current wording ("the child uses its own configured permissions") is easy to read as sandboxing when it is the opposite.
2. Consider an inheritance or approval gate so a parent that cannot write cannot spawn a writer.

Frequency: reproducible on demand, not intermittent. Workaround: manually run the subagent with an implementation prompt only after explicitly leaving plan mode.

Unrelated note for the reporter's repo, not part of this issue: the same machine carries a second, untracked project inside the working tree that Tailwind auto-content-detection scans, leaking style rules into the first project's build output. Filing separately if wanted.