fix(task): only inherit edit-class denies from parent agent to subagent

[21pounder]

Issue for this PR

Closes #26700

Type of change

• Bug fix

What does this PR do?

#26597 fixed a Plan Mode security bypass by having deriveSubagentSessionPermission() append all parent agent deny rules into the child subagent's session permission. This broke deny-by-default multi-agent configurations where the primary/controller agent is intentionally narrow and delegates to a subagent with its own explicit allowlist.

Root cause: Permission.merge(agent.permission, session.permission) is evaluated with findLast (last-match-wins). The inherited parent denies land at the end of the merged ruleset, so they override the subagent's own allow rules. The subagent's tools disappear from its tool inventory before the LLM ever sees them.

Fix: Only inherit edit-class denies (edit, write, apply_patch) from the parent agent — these are the permissions that matter for the Plan Mode ceiling. Other parent denies describe what the parent itself cannot do and must not constrain the subagent's own explicit allowlist.

The change is one filter condition in src/agent/subagent-permissions.ts:

// before
const parentAgentDenies = input.parentAgent?.permission.filter((rule) => rule.action === "deny") ?? []

// after
const EDIT_PERMISSIONS = ["edit", "write", "apply_patch"]
const parentAgentDenies =
  input.parentAgent?.permission.filter(
    (rule) => rule.action === "deny" && EDIT_PERMISSIONS.includes(rule.permission),
  ) ?? []

How did you verify your code works?

Added a regression test in test/agent/deny-by-default-subagent-bypass.test.ts that mirrors the controller → executor config from the issue. The test asserts that executor's read, bash, and task allows survive after deriveSubagentSessionPermission, and that edit/write are still denied (Plan Mode ceiling preserved).

Also ran the existing test/agent/plan-mode-subagent-bypass.test.ts to confirm the original #26514 fix is not broken. All 6 tests pass.

Verified end-to-end with a live bun dev session using the minimal config from the issue. Before the fix, the executor session was created with read * -> deny and bash * -> deny inherited from the controller. After the fix, only edit * -> deny and write * -> deny are inherited, and the executor successfully reads files.

Screenshots / recordings

Before fix — executor session created with all controller deny rules inherited:

After fix — executor session only inherits edit-class denies:

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR