What

A restricted agent's tool restrictions live on its agent ruleset, but a dispatched subagent ran with its own (often broader) permissions — so a read-only or Plan-Mode caller could escalate by spawning a more-capable subagent that edits files, runs bash, or reaches the network.

Why

Semantic port of anomalyco/opencode#26597 — "subagent inherits parent agent's deny rules (Plan Mode security bypass)" — adapted to PawWork's permission model.

How (single source of truth: the child's session.permission ruleset)

At dispatch the agent tool forwards the caller's deny rules onto the child session.permission — patterns intact — so scoped denies (edit on one path), whole-tool denies, and wildcard ("*") denies all reach the child as real rules, not a lossy boolean map. Both gates that bind a tool already evaluate merge(subagentAgent.permission, session.permission):

• availability — Permission.disabled hides whole-tool denies from the model;
• ask — the runtime/subtask ask gate evaluates the same merged ruleset.

So a forwarded deny binds the child the same way it bound the caller. The caller agent's restrictions live on its agent ruleset (not the session), so they are forwarded explicitly; the caller session/per-prompt denies and external_directory rules carry over too.

SessionPrompt.prompt still rebuilds session.permission from the boolean tools map the agent tool passes, but that map is now availability-only — it lists the subagent's structural constraints (no nested dispatch, no worktree switching, no todos/primary-only tools), not caller-inherited authorization. For an agent-tool child the rebuild carries forward the caller's inherited rules the map can't regenerate:

• external_directory rules (workspace scoping),
• scoped (non-"*") denies — e.g. edit on one path,
• whole-tool denies for keys the map doesn't list — the wildcard "*" and unlisted tools (automate, MCP, custom).

Whole-tool denies for keys the map does list are regenerated from the map each turn, so the ruleset stays stable instead of accumulating; non-agent sessions still replace wholesale (pre-existing behavior).

Caller resolution. ctx.extra.callerAgent ?? ctx.agent: on a normal LLM dispatch ctx.agent is the caller, but SessionPrompt.handleSubtask runs the agent tool as the child, so it threads the real caller through ctx.extra (PawWork sessions don't store their agent; upstream reads parent.agent). edit covers edit/write/apply_patch (all ask under the single "edit" key).

Resume. subagent_session_id resume skips sessions.create, so the inherited permission is recomputed from the current caller and re-applied onto the existing child before it runs — otherwise a caller that became more restrictive after the child was created (e.g. switched to Plan Mode) could resume it and regain the denied tools, since the child still carried its original creator's permission.

Architecture note (why one channel, not two)

An earlier revision bound the subagent in two places — a fixed guarded-tool list evaluated into the boolean tools map and the forwarded ruleset — and that two-channel design produced a string of review regressions (scoped denies dropped, unlisted/MCP tools dropped, wildcard handling) because the boolean map is lossy: it can only express a per-tool "*" rule. A first-principles review (independently confirmed) showed the two channels are redundant: the forwarded ruleset on session.permission already drives both the availability gate and the ask gate, so the boolean channel never added coverage. This revision collapses to the single ruleset channel — the boolean map reverts to availability-only — which is what the model can actually represent and what the rest of the permission system already evaluates.

Tradeoff (matches upstream)

Forwarding is deny-only: a wildcard caller's allow-exceptions (e.g. a read-only "*": deny agent that also allows read) are not preserved, so its subagent loses those tools too. This errs toward deny and matches upstream's deriveSubagentSessionPermission. The linear allow/deny/last-wins ruleset can't express "intersect with the caller" without enumerating every tool (including dynamic MCP/custom ones), which isn't possible at dispatch — so deny-only is the faithful, safe choice.

Boundary

• packages/opencode/src/tool/agent.ts — resolve the real caller and forward its deny rules onto the child session at create (the single source of truth); the tools map is availability-only
• packages/opencode/src/session/prompt.ts — handleSubtask passes callerAgent; the permission rebuild carries external_directory + scoped + unlisted/wildcard denies forward for agent-tool children (core-rebuild change authorized for a fully-correct fix)
• packages/opencode/test/tool/agent.test.ts, packages/opencode/test/session/prompt.test.ts — regression tests

Verification

• bun test test/tool/agent.test.ts + bun test test/session/prompt.test.ts -t "subagent permission rebuild": the child's effective ruleset denies a tool the caller denies (explicit edit/bash, wildcard, caller session deny, subtask-caller-override), no over-restriction when the caller can use the tool, caller-agent scoped deny forwarded at create, resume re-forwards the current caller's deny onto an existing child; the rebuild carries scoped + external_directory + unlisted/wildcard denies forward for agent-tool children, regenerates listed whole-tool denies without double-carrying, and replaces wholesale for non-agent sessions.
• bun test (full opencode suite) — 3661 pass / 0 fail.
• bun run typecheck — clean.

Scope / severity

Privilege escalation reachable via a non-default config: an agent that denies edit/bash/a scoped path/"*". Default agents don't hit it. Labeled P2 on that basis.