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

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

Start in extensions/cli/src/subagent/executor.ts around lines 85-88 and trace how TOOL_PERMISSIONS state is replaced before subagent execution and restored afterward. Review the permission service state and subagent entry path to determine how the main agent's restrictions should be retained. Done means configured restrictions remain effective during the full subagent run, including disabled tools, without leaving permissions altered afterward.