fix: security boundary hardening, stream/scrollback bounds, SDK-compatible auth

[ForkedInTime]

Four commits from a phased review of the codebase. Two are security fixes, one closes a
class of hangs and an OOM, one adds credential resolution matching the official SDKs.

524 tests pass, 0 failures. Clippy clean at --all-targets --all-features.
Every new test was verified to fail against its reintroduced bug — details per section.

---

1. PowerShell bypassed both security controls (96545c6) 🔴

The most serious finding. PowerShellTool is in the live tool registry and executes
arbitrary commands, but:

• "PowerShell" was absent from SENSITIVE_TOOLS, so check_with_input returned Allow
  on the non-sensitive early return — no approval prompt, ever
• apply_sandbox was called from bash.rs and nowhere else — never sandboxed

On any machine with pwsh installed, the model could run shell commands unprompted and
unsandboxed. Explicit deny rules still applied (they are checked before the early return),
but the default posture was open.

Adds it to SENSITIVE_TOOLS, teaches rule_matches/describe_tool_call about it, and routes
it through a new sandbox::guard_unwrappable_tool. The namespace wrappers hard-code
/bin/sh -c and cannot correctly wrap a PowerShell script, so that gate applies pattern
blocking in every mode and fails closed under bwrap/firejail rather than running outside
the sandbox the user enabled.

2. Sandbox failed open (96545c6) 🔴

apply_sandbox's _ arm returned the command unchanged — unsandboxed and skipping
strict_check — while the UI still reported the sandbox as enabled. Reachable in practice:
/sandbox enable validates the mode string but settings.json does not, so a typo in
sandboxMode silently disabled the sandbox. Now fails closed and names the bad value.

Separately, firejail_wrap took no allow_network parameter, so firejail mode always had
full egress while bwrap honoured the setting — the same config meaning two different things.

3. Unbounded output buffering, and inherited stdin (96545c6)

BufReader::lines() accumulates until it sees a newline, so newline-free output
(yes | tr -d '\n') buffered the whole stream into one String; the MAX_OUTPUT_BYTES
check ran per line and never tripped.

Capping the reader alone is the wrong fix — the child then blocks on a full pipe and every
command over the cap burns the entire timeout. Measured: 60s vs 1.2s. Switched to chunked
reads so output is bounded while the pipe keeps draining, and the child still exits. Partial
lines are carried as bytes so multi-byte UTF-8 spanning a chunk boundary is not mangled.

Both Bash and PowerShell also inherited the TUI's stdin, so an interactive command (sudo,
ssh, a bare read) competed with crossterm for the user's keystrokes and hung until timeout.
Now redirected from /dev/null.

4. SSE streams could hang forever; TUI scrollback grew without bound (c920568)

Both streaming backends awaited the next event with no bound — only connect_timeout was set.
A silently dropped TCP connection (NAT reaper, laptop sleep, VPN drop) parked the read future
forever: the UI hung with no error and no recovery. The defect was in two backends, and
since openai_compat also serves Ollama, all three streaming paths were exposed. Fixed once
via a shared next_sse_event() with a 120s inter-event budget — deliberately not a
whole-request timeout, so legitimate multi-minute streams are untouched.

app.entries had no cap (input_history did, at 500), so a long agent loop grew memory
monotonically. It is display-only state — the transcript lives in messages and persists to
the session file — so eviction loses no conversation data. Trims at 2000 while following the
newest content, deferring to a hard 10000 ceiling while scrolled up so history is not yanked
out mid-read.

Also cost.rs used partial_cmp().unwrap() on f64; the release profile sets
panic = "abort", so a non-finite cost would have killed the session to render a report.

5. Credential resolution matching the official SDKs (8b3feea, 91399e0)

RustyClaw read ANTHROPIC_API_KEY and nothing else, ignoring credentials the user may already
have configured for Claude Code, the official SDKs, or the ant CLI — all of which share one
documented order. Adds src/auth.rs implementing it:

ANTHROPIC_API_KEY → ANTHROPIC_AUTH_TOKEN → ant auth login profile

RustyClaw's own explicit mechanisms (RUSTYCLAW_API_KEY_FILE_DESCRIPTOR, apiKeyHelper) keep
their existing position between the env vars and the profile — explicit local config should
beat ambient machine state, and nothing that worked before changes.

Wire format now follows the credential kind: a static key goes in x-api-key; an OAuth token
goes in Authorization: Bearer and requires the oauth-2025-04-20 beta. The beta is
merged into the per-request anthropic-beta rather than set as a default header, because
reqwest's header() appends — a default plus a per-request value would send the field twice.

Profile tokens come from ant auth print-credentials --access-token rather than parsing
credentials/<profile>.json. That command refreshes the short-lived token before printing, so
there is no OAuth refresh flow to implement, and it keeps us on a supported interface
instead of an on-disk format that is an implementation detail. Bounded at 10s so a wedged
binary cannot hang startup.

Deliberate divergence from the SDKs: an empty ANTHROPIC_API_KEY="" falls through with a
warning rather than winning its slot and authenticating with an empty key. /doctor now
reports which source won and surfaces the "stale env var is shadowing your profile" trap.

91399e0 fixes a real defect this surfaced: the .env allowlist (SAFE_ENV_KEYS) contained
ANTHROPIC_API_KEY but not ANTHROPIC_AUTH_TOKEN or ANTHROPIC_PROFILE, so a project
authenticating with a token from .env would have had it silently dropped.
ANTHROPIC_BASE_URL stays excluded — it redirects every API call, so a hostile repo .env
could point real credentials at an attacker-controlled host.

Verified end-to-end against the live API, with HOME redirected to an empty directory so
no ~/.env could repopulate the variable:

Setup	Result
both credentials set	invalid x-api-key — key wins, sent as x-api-key
key absent, bogus token	OAuth access token is invalid — sent as bearer, recognised as OAuth
key "", bogus token	same — empty value correctly ignored
neither set	new guidance message listing all four sources

---

Verification method

Every fix has a regression test that was confirmed to fail against the reintroduced bug:

• removing PowerShell from SENSITIVE_TOOLS → 3 tests fail
• restoring the fail-open sandbox arm and dropping the firejail flag → 3 tests fail
• neutering scrollback eviction → 3 of 5 fail (the 2 that pass are the correctly-non-evicting cases)
• removing the SSE timeout → the stall test hangs until killed (exit 124), the production symptom
• reverting total_cmp → panics at the unwrap

Not addressed here

Left open in the review tracker, deliberately out of scope for this PR:

• strict_check is a lowercase substring blocklist (rm -fr / passes) and is the automatic
  fallback on macOS/Windows, where neither bwrap nor firejail exists
• bwrap omits --new-session (TIOCSTI keystroke-injection class)
• hooks.rs has no timeout, no output cap, and fails open twice — a hook that fails to spawn
  returns allow(), and a signal-killed hook is treated as success via unwrap_or(0)
• Workload Identity Federation (4th in the credential chain) is not implemented

Note for reviewers

env -u ANTHROPIC_API_KEY does not give you an absent variable in this codebase —
load_dotenv_auto() repopulates any allowlisted key from ~/.env when it is unset. Redirect
HOME to test a genuinely-absent credential. This cost a debugging cycle and is now recorded
in the tracker.