Sticky in process, gone on restart: auditing the state your CLI daemon keeps in memory

Description and use

The --allowed-domains flag in the agent-browser CLI loses its containment boundary after the daemon restarts because the state is kept only in process memory. The result is an open security boundary. Persist the state in a sidecar file or enforce a fail‑closed policy.

Problem

A containment flag (--allowed-domains) in the agent-browser CLI disappears silently after the daemon restarts, causing a security boundary to fail open.

Outcome

The audit revealed that the --allowed-domains flag is only sticky within a single process, leading to a silent drop of the containment boundary on daemon restart. By persisting the boundary or enforcing a fail‑closed policy, the security posture can be restored.

Workflow

• 1. Identify the flag that enforces a policy (e.g., --allowed-domains).
• 2. Determine where the value enters the daemon (flag, env var, file).
• 3. Check who adopts it and for how long (in‑process inheritance).
• 4. Verify the baseline state at process start (environment only).
• 5. Ensure the baseline is persisted safely (atomic write, permissions, fsync).
• 6. Decide if the boundary should fail open or closed when baseline is absent.
• 7. Implement persistence (sidecar file) or fail‑closed logic as needed.
• 8. Expose the effective boundary in session‑info for client verification.

Evidence

The first is --allowed-domains, which restricts the browser session to a set of domains. Its inheritance behaviour inside a running daemon is, as far as I can tell, exactly what you would want.

Source

What a new process gets instead is the bare environment. DaemonState::new seeds the filter from one variable: AGENT_BROWSER_ALLOWED_DOMAINS.

Source

The second flag is --pin-tab, a weaker boundary with the identical failure mode. It was made restart-proof with a sidecar file...

Source