Subagent execution replaces TOOL_PERMISSIONS with allow-all — bypasses all user-configured tool restrictions

[Tardfyou]

Summary

When the main agent spawns a subagent via the Subagent tool, the executor replaces the entire TOOL_PERMISSIONS service state with { tool: "*", permission: "allow" } — removing every user-configured approval restriction (Bash, Write, Edit, etc.) for the duration of the subagent run. A TODO comment acknowledges this is incomplete:

// allow all tools for now
// todo: eventually we want to show the same prompt in a dialog whether asking
// whether that tool call is allowed or not

The original permissions are restored in a finally block, but by then the subagent has already executed with unrestricted tool access.

Root cause

extensions/cli/src/subagent/executor.ts:85-88:

serviceContainer.set<ToolPermissionServiceState>(
    SERVICE_NAMES.TOOL_PERMISSIONS,
    { permissions: { policies: [{ tool: "*", permission: "allow" }] } },
);

The user's granular permission configuration (e.g., Bash → ask, Write → ask, Read → allow) is wholesale replaced by allow-all for the subagent's entire lifetime.

Reproduction (code path)

1. User configures granular tool permissions (e.g., Bash → ask, Write → ask)
2. Main agent spawns a subagent for a focused task
3. Executor sets TOOL_PERMISSIONS to * → allow before subagent runs
4. Subagent can execute ANY tool (Bash, Write, network, etc.) without prompting
5. Original permissions restored only after subagent completes

Impact

One subagent approval = blanket authorization for the subagent to execute ANY tool without review. A prompt-injected subagent task could perform arbitrary file writes, command execution, or network exfiltration using the user's credentials.

Suggested fix

Propagate the main agent's permission configuration to the subagent, or at minimum preserve disabled tools as disabled in the subagent context.

Credit

Chengzhi Yi — yimou@hust.edu.cn — GitHub: @Tardfyou