#97 feat(approvals): replace the binary approve-everything toggle with a five-level ladder

[Anonymous]

Originally created by: sosidudku1

Problem

The approve-everything switch shipped in [#81] is all or nothing: either every gated action interrupts the operator, or nothing does. There is no way to say "let the agent edit files in this project, but keep asking before it touches my home directory or runs shell commands".

Change

agent.approvalRequired becomes a five-step agent.approvalLevel (config v37, transparent migration: false maps to 5, true or absent to 1). Every requireApproval call site names a category from a closed union; the gate auto-approves when the live level covers the category (O(1) table lookup).

• L1 paranoid (default) - everything asks.
• L2 workspace - file write/edit/patch strictly inside the session cwd (realpath containment; symlinks, including broken ones, classified by target).
• L3 home - + home-directory file ops, Trash, archive extraction, HTTP (SSRF guard untouched).
• L4 operator - + guard-flagged shell, skill scripts, process kills.
• L5 full trust - everything, including non-web browser navigation.

Writes outside both workspace and home fall to a conservative bucket that asks everywhere below 5. Hardline shell-guard rules still block before the gate at every level; MCP stays outside the gate. The Privacy tab shows the ladder (keys 1-5 and arrows, level 5 in the error color) with an honest cumulative coverage list; /privacy level 1..5 is new and /privacy approve on|off survives as the alias pair for 5 and 1; --no-approval keeps its one-directional contract. GET /api/capabilities reports the live approvalLevel plus a derived approvalRequired (level < 5) for binary-field clients.

Security boundaries

• No silent self-escalation. The files that define the agent's own trust surface, <stateDir>/config.json (holds agent.approvalLevel) and <stateDir>/.env (API keys / bot tokens loaded at boot), are categorised trust_config, pinned at level 5. A write, edit, patch, or trash of either always prompts below full trust, so a model at level 3 or 4 cannot raise its own level or swap a token for the next boot without an explicit approval. Matching is by canonical realpath (and dangling-symlink target), so a symlink or .. detour to the config is caught, not just a literal path.
• Dangling symlinks are classified by target. Workspace containment resolves where a write actually lands, including broken leaf symlinks: a link inside the project pointing at a not-yet-existing file outside it is treated as an outside write, never a silent workspace write.
• Level changes are machine-local. /privacy level is TUI/CLI only; there is deliberately no Telegram command to change the standing trust level, so a compromised bot token cannot silently widen trust. Remote operators still approve each gated action per-request.
• Unchanged. Hardline rules block before the gate at every level; MCP stays outside the gate; the SSRF guard on HTTP is independent of the ladder.

What this deliberately does not do

No prompt-side awareness of the level (that is [#79] territory, still deferred), no per-project or per-session overrides, no category forwarded over the sidecar protocol yet.

Testing

Table test pinning the full category-by-level matrix; realpath categoriser tests (symlinks out of the workspace incl. dangling, not-yet-existing targets, prefix attacks, multi-path combining, config/.env decoys); config migration tests including the on-disk v36 to v37 rewrite; gate hot-apply both directions; TUI render of all five levels plus key bindings and slash commands; capabilities route; and level-2 and level-4 end-to-end tests through the real runtime (workspace write silent, home write prompts, config.json write at L4 prompts as trust_config, rm -rf / hardline-blocked). Full suite delta against origin/main is zero new failures. Builds on [#81]; related to [#79].

[Anonymous]

Ticket changed by: Ooooze

• status: open --> closed