A permission fix can look smaller than it is.
In OpenCode commit 3ad6923c, contributor Aiden Cline changed how a subagent session derives permissions when it is spawned through the task tool. The prior test framing treated plan-mode inheritance as the core safety issue. The merged patch instead draws a sharper line: parent session denies still pass through, but parent agent restrictions do not erase the subagent's own permission model.
The old bug became a product question
The diff removes inheritance of the parent agent's edit-class deny rules from `deriveSubagentSessionPermission`. The helper now carries forward parent session deny and `external_directory` rules, then lets the subagent's own rule set decide its capabilities. The tests were rewritten around that stance: "subagent permissions take precedence over parent agent restrictions," while a separate test keeps parent session deny rules as hard runtime ceilings.
That is a useful distinction for agent systems. A plan agent may be read-only because its job is planning. A spawned executor may need edit authority because its job is execution. But a session-level deny, such as a runtime ceiling on bash, should still bind the child. The patch is not simply less restrictive; it separates role policy from session policy.
The default stays cautious
The same commit adds a default plan-agent rule that denies the general subagent unless user configuration allows it. Tests cover both sides: plan mode denies `task: general` by default, while explicit user permission can allow the general subagent from plan mode. That keeps the design from becoming invisible delegation. Users can cross the boundary, but the default asks them to say so.
The article should credit the exact visible work and stop there. The public commit identifies Cline as the author. It does not prove private motivation, employer direction, or a broader roadmap. The fair question for the contributor thread is factual: which real workflows needed subagent permissions to remain independent from parent agent restrictions?
The same contributor hardened MCP edges
Cline's nearby OpenCode commits make the permission patch less isolated. Commit 174ab583 applies per-server timeouts to MCP prompt and resource requests, with tests proving a configured 2500ms timeout reaches both calls. Commit 07b983e8 wires MCP server log notifications into OpenCode's logging levels.
Taken together, the public record shows maintenance work around delegated work: what a child agent may do, how long external MCP prompt/resource calls may wait, and where server-side MCP messages appear. That is first-coverage evidence for OpenCode as a serious agent runtime subject, not only another terminal UI.
Why this belongs in the edition
Recent editions have covered preflight trust, scheduled operations, and live agent control. OpenCode adds a different pressure: delegation needs a permission model that can express role independence without losing runtime ceilings. That is a practical builder problem. If every child inherits the parent's role restrictions, delegation becomes ceremonial. If no parent/session boundary survives, delegation becomes a bypass.
The June 11 patch lands between those failures. It says the subagent is allowed to be its own worker, but the session can still set the floor. That is a small diff with a clean human arc: a contributor turns an issue-shaped safety worry into a design choice maintainers can test, document, and argue about.