fix(security): gate brain-emitted tool calls on the local chat path

[AetherAI3]

Summary

runLocalTurn dispatched every brain-emitted tool_call straight to ToolExecutor.executeAsync, so a model-chosen run_shell command reached ToolExecutor.run -> spawnSync(command, { shell: true|ComSpec }) with no executable allow-list and no approval — while the code command gated the identical sink through decideGate. A guard only some callers apply is not a guard.

Found by Predator as AGENT-CMD-001. Least-privilege / guard-completeness finding, not a live exploit: it needs a user-initiated local session and a model-emitted command. The Agent's file tools were never affected — ToolExecutor.safe() canonicalizes then enforces within-root.

The change

Gate construction moved out of commands/code.ts into core/tool_gate.ts; both commands build it from there so they cannot drift apart again. Policy is unchanged — decideGate remains the single source of truth and the shared module only performs the prompt I/O it asks for.

interactive terminal      -> y/N prompt showing the actual command
--yes / permissionMode    -> explicit operator opt-out, no prompt
non-interactive terminal  -> FAILS CLOSED, the call is refused

A refused call is never executed; the brain receives {output: "[denied: <tool> not approved by user]", exitCode: 1} and the turn continues.

UX note, deliberate: local chat now prompts when the model asks to mutate or run something. Read-only tools (read_file, repo_search) are unaffected, so ordinary chat is unchanged.

Test plan

test/tool_gate.test.ts:

• read-only tool allowed silently
• TTY prompts, with the real command shown to the operator
• declining refuses the call
• --yes opts out without prompting
• no TTY fails closed and never attempts a prompt
• skip mode allows
• long commands truncate in the prompt
• deniedResult shape
• chat-path source invariant: gate built and consulted before executeAsync, deniedResult on refusal
• neither command re-implements decideGate inline (anti-drift)

632/632 tests pass.

Residual, recorded not fixed here

src/core/smoke.ts also dispatches brain tool calls ungated. It runs a fixed internal SMOKE_PROMPT and has no command-surface caller, so it is lower severity and deliberately out of scope for this focused repair.

[AetherAI3]

Closing this as a security repair — current main already has the complete fail-closed command gate, so there is nothing here to fix.

Evidence

main gates the local chat path today:

Location	What it does
src/core/tool_registry.ts:42	run_shell: { sideEffect: "shell" }
src/core/autonomy.ts:70	decideGate → !isTty ? "deny" (fails closed), yes ? "allow", else "prompt"
src/commands/chat.ts:236	await approveTool(...) before exec.executeAsync
src/core/diagnostics.ts:194	asserts gateActionFor("run_shell") === "shell" as a runtime invariant

That is the same policy this PR proposed — interactive prompt, --yes opt-out, deny on non-TTY — reached through decideGate rather than a new core/tool_gate.ts.

Why the finding looked live

The scanned commit d26e0bc sits on a branch that forked from main at 5cf2d4d (2026-07-10). The upstream gate landed in cf16578 (PR #44) on 2026-07-14, four days later, and cf16578 is not an ancestor of d26e0bc. So the scan ran against code that predated the fix and correctly found no gate on that branch. It was never an ungated path on main.

AGENT-CMD-001 stays valid as a historical-commit finding and keeps its replay receipts. It is being removed from active production coverage and from the production seal, since it was never default-branch-bound.

Not lost

The workflow-viewer agent panel (c6bbab6 + d26e0bc, ~700 lines across src/ui/workflow_viewer.ts, src/core/brain_protocol.ts, src/core/stream.ts and their tests) is unrelated to the security claim and is untouched by this closure. It can come back as its own feature PR if still wanted — every rebase conflict against current main came from those two commits, not from the gate.