feat(server): agents start with the project's direnv environment

[otavio]

What Changed

Provider sessions now load the direnv environment (.envrc) of their workspace, the way a shell with the direnv hook does. This applies to every provider: Codex, Claude, Cursor, Grok, OpenCode and Antigravity.

• Trust stays with direnv. Only .envrc files approved with direnv allow are loaded. A blocked, failing or timed-out one shows as a thread warning, and the agent starts without it.
• Checked before every message. On a reused session, the server runs direnv's own staleness check against the environment the session started with. If nothing changed, it only compares file timestamps and takes milliseconds. If the user allowed or edited .envrc, or a watched file such as flake.lock changed, the session restarts from its saved state and picks up the new environment, so no new thread is needed.
• One evaluation per checkout. Threads that start together in the same checkout share a single evaluation, because a first nix develop can take minutes.
• Allow .envrc. A blocked-.envrc warning has this button on web and mobile. It calls a new projectEnvironment.allowDirenv RPC with the orchestration:operate scope. The server resolves the .envrc from the thread, so a client cannot allow an arbitrary path.
• Setting. "Load direnv environment" is on by default and can be overridden per environment or per project (Settings → General on web, Agent behavior on mobile).
• Precedence. Variables set on the provider instance, such as CODEX_HOME or CLAUDE_CONFIG_DIR, win over the .envrc.
• Docs. A "Project environments with direnv" section in docs/user/project-settings.md.

Why

Projects that provide their toolchain through direnv (Nix dev shells, devenv, mise) only worked in integrated terminals. Agents never run through a shell, so they started without the project's tools, compilers and pinned runtimes.

UI Changes

A blocked .envrc warning in the thread timeline gets an Allow .envrc button. After you click it, the button reads "Allowed · applies to your next message". Dev-server run against a demo project:

What the screenshot shows:

1. The first answer is NOT SET: the .envrc was explicitly denied, which the server honours silently.
2. The .envrc was edited, so direnv no longer trusts it. The per-message check picked this up and posted the blocked warning with the button.
3. After Allow, the next message restarted the session, and the agent read loaded from .envrc.

Warnings with an action stay on their own row instead of folding into a collapsed work group (web and mobile), and the button keeps its state when the timeline remounts the row.

This PR also adds a "Load direnv environment" toggle in Settings → General (web) and Agent behavior (mobile). Screenshots of the toggle and of mobile are still to come.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (timeline done; settings and mobile pending)
• I included a video for animation/interaction changes

Verification

• The affected suites pass for server, contracts, client-runtime and web (including the full server.test.ts WebSocket suite).
• contracts, client-runtime, web, mobile and server typecheck.
• Checked against the real direnv binary: blocked, then allow, then load, then an unchanged check. Editing the .envrc blocks it again, and after a new allow the check detects the change and loads the new values.

Not included

There is no "Loading project environment…" status while a slow evaluation runs; the thread shows the generic working timer. Adding that needs a progress field or activity that nothing carries today, so it is left for a separate PR.

---

Done with Claude Opus 5.5 in Claude Code (via T3 Code).