Per-session policy isolation (allowlists, rate limits, audit grouping)

[cuihtlauac]

Problem

The session field on Request (src/protocol.rs:12-13) exists but is purely informational — it's printed in the TUI and (with -v) in the daemon log, and that's it. Two different Claude Code projects sharing one workstation hit the same socket, the same TUI gate, and would share the same policy and audit grouping if those existed.

This is fine today because the only gate is the TUI keypress. It stops being fine the moment we add policy: an allowlist that's appropriate for project-A ("this agent may run apt update without prompting") leaks to project-B by default. Same for rate limits, same for audit-log filtering, same for any per-session quota or cooldown.

Proposal

Keep one socket and one daemon — adding per-session sockets multiplies bookkeeping (which one is running? who cleans them up?) for little gain. Instead make session a first-class policy key inside the existing daemon:

• Validate session strictly (alphanumerics, dots, dashes, underscores; bounded length). Reject anything else at request parse time. Today it's free-form.
• Index per-session state in the daemon: the replay-protection set (src/server.rs request-id dedup), any future allowlist (Policy framework: allow / require-approval / deny per (session, host, command) #9), any future rate limit, and audit-log filtering (Append-only audit log of approved requests and outcomes #6) all key off session in addition to host.
• Display session more prominently in the TUI prompt — it's the principal that the operator is gating, not just metadata.
• The MCP server already sets session: \"sudo-proxy-mcp\" for every call (src/mcp.rs:145). That's the bug this issue exposes: a single MCP server serving multiple Claude Code projects would conflate them. Plumb the project name (or .mcp.json directory hash) through as the session, so each project gets its own bucket.

Things to consider:

• This is a multiplier on Append-only audit log of approved requests and outcomes #6 (audit log) and Policy framework: allow / require-approval / deny per (session, host, command) #9 (allowlist), not standalone value. Land those first or in parallel; on its own this issue mostly tightens validation.
• Naming: bikeshed-prone. session is what's on the wire; consider whether the policy layer should call it principal or tenant internally to keep the concepts separable.
• Backwards compatibility: existing sudo-request --session NAME callers and the default \"unknown\" (src/protocol.rs:33-35) must keep working. Stricter validation should reject obviously hostile sessions but not break legitimate ones.