#81 Privacy tab: approve-everything toggle over the approval gate

[Anonymous]

Originally created by: sosidudku1

Towards [#79].

Problem

agent.approvalRequired existed only as a config.json key, so users hitting repeated approval prompts had no way to turn them off without a restart or hand-editing config.json, and nothing on screen said where the switch lives.

What's in

• Privacy tab toggle. "approve everything" (y) next to the analytics opt-out. Applies live (no restart) and persists to config.json. The ON label states the cost plainly: "on (the agent runs every action without asking)", rendered in the error color while active.
• Discoverable from the prompt itself. The approval banner footer now says: "y approves this call only; turn approvals off on the Privacy tab (/privacy)".
• Palette path. /privacy approve on|off mirrors /privacy analytics on|off; the target state must be named, there is no bare toggle form.
• Honest coverage copy. The panel lists what the gate covers: shell commands, file writes and deletes, HTTP requests, process kills, script runs, and browser navigation to non-web URLs (file://, javascript:). Hardline shell-guard rules still block catastrophic commands either way (they fire before the gate).
• Single live switch. Tools always register approvalRequired: true; the ApprovalGate's autoApprove flag carries the boot value, so runtime.setApprovalRequired flips approvals in both directions without a restart. Boot behavior is unchanged; a new bootstrap test pins the invariant end to end.
• serve alignment. serve now resolves approvals like run and tui: the persisted agent.approvalRequired is the baseline and --no-approval can only force approvals off, never back on. Previously serve read only the flag, which made the panel promise "applies to future runs too" false for serve.
• Live capabilities. GET /api/capabilities reports runtime.isApprovalRequired() instead of the frozen boot snapshot, fixing the stale value under serve --no-approval and after live toggles.
• Divergence is named. If persisting succeeds but the hot-apply throws, the error says config.json was already rewritten and the next start uses the new value.

What this deliberately does not do

Issue [#79] first asks for "always allow this session / always allow this command shape" options inside the approval prompt itself, and recommends the session-scoped grant as the safer default. That variant needs a richer ApprovalGate resolve protocol (scoped grants, command-shape matching) and is deferred to separate work; the issue's session-scope recommendation stands. This PR ships the coarse global switch plus a pointer to it from the prompt, so the fatigue path has an exit today.

Tests

• ApprovalGate live flip in both directions; bootstrap end-to-end pin: a no-approval boot flips back to interactive prompts (tools are not frozen)
• Panel copy pins (coverage list incl. browser navigation), approval prompt footer pin
• /privacy approve on|off dispatch, usage guard, and callback mapping
• GET /api/capabilities follows the live gate state
• serve boot contract truth table
• Orchestrator persist-vs-hot-apply divergence error, plus the toggle suite from the base commit (gate, reducer, persist, orchestrator)

[Anonymous]

Ticket changed by: Ooooze

• status: open --> closed