Opt-in browser automation budgets and a readiness signal for coding agents

[Akilleez-QA]

Could Omarchy offer an opt-in browser automation launcher and a machine-readable readiness signal for coding agents?

When several agent sessions run browser checks on the same workstation, each can make reasonable decisions locally while their combined workload competes with the interactive desktop. Agent instructions can recommend restraint, but separate sessions need a shared admission mechanism and a current signal telling them when to defer browser work.

The proposed first contribution is deliberately small:

• An explicit automation launcher, separate from interactive browser launch behavior, with a configurable concurrency budget, minimum launch interval, and runtime limit. Excess work should receive a bounded, actionable refusal rather than silently launch or spin in retries.
• A JSON status command exposing readiness, occupied capacity, cooldown, and the reason work should be deferred. Status is advisory; the launcher must make the actual admission decision atomically.
• Short guidance in Omarchy's agent skills explaining how to select the launcher, reuse browser contexts, close owned work, and handle busy/unknown/degraded results without bypassing the guard. Existing agent sessions would need to reread the guidance.

Illustrative command names, not a proposed final CLI:

omarchy agent browser status --json
omarchy agent browser run -- <browser executable> <arguments...>

This would govern participating automation only. Embedded browser tools that cannot select a launcher would remain outside enforcement. It should preserve literal arguments, exit status, cancellation, and Playwright's pipe transport; use private per-user state; avoid interactive profiles; and never broadly kill browsers or reset the display GPU. A cooperative process-group supervisor is not a sandbox, and a cgroup alone should not be assumed to contain Chromium when it creates its own application scope.

Optional hardware-health adapters and bounded diagnostics could follow separately. They should distinguish unsupported or stale evidence from healthy readings. In particular, free framebuffer VRAM does not prove that GPU virtual-address mappings are available. A vendor-specific monitor should not become a default dependency for every machine.

The motivation was an unclean shutdown on an NVIDIA/Wayland workstation, preceded by repeated mapping-allocation failures and an application crash. The cause remains unresolved: there is no proof that coding agents caused the freeze, and counts of Chromium-named systemd scopes are not counts of browser roots or concurrent sessions. This suggestion is about workload coordination and feedback, not a claimed driver fix or a verified Omarchy bug.

A local prototype now uses a shared supervised launcher, continuous byte-bounded GPU evidence, independent freshness checks, and persistent agent guidance. It passed 24 synthetic tests covering admission, cancellation, orphan detection, stale health, file handling, and rollback; a real headless Playwright about:blank launch verified pipe compatibility and cleanup. A live stop/restart check verified stale-status refusal and recovery. Those observations establish the exercised boundaries, not long-term prevention of desktop freezes. The prototype's paths, NVIDIA assumptions, and policy defaults need generalizing before an upstream patch.

Related work, with different scope:

• ~/.config/chromium-flags.conf is force-injected into every chromium launch, crashing headless/automation invocations (Playwright etc.) with SIGTRAP #11085 and Chromium crashes with SIGTRAP on exit when automated via DevTools/Playwright due to flags conflict and single-process teardown #15773 discuss Chromium flags/automation crashes; this proposal would need to respect that compatibility boundary, not assume their diagnoses explain this incident.
• Avoid focusing custom agent browsers when opening links #15634 addresses interactive focus around custom agent browsers.
• Discussion Proposal: Post-Task Reflection, Persistent "Gotchas", and a Community Recipe Hub for OpenCode/Omarchy #11485 proposes persistent agent gotchas; this adds live readiness and shared admission rather than another memory system.

Would maintainers prefer a small core launcher/status contract with agent documentation, or an external optional tool documented by Omarchy? I'd target a focused PR once that ownership boundary is agreed, keeping GPU diagnostics separate.

AI assistance: GPT-6 via Codex. Submitted on the user's behalf; validation claims above describe the local prototype only.

[rhkiswani]

One data point from the other side of the boundary you draw ("embedded browser tools that cannot select a launcher would remain outside enforcement"). In Mars (the browser we are building in Rust, with its own agent interface) we put the admission inside the browser instead of in front of it, and it covered that gap for free.

How it works: one browser process listens on a per-user unix socket (0600, private directory, fresh token per run) and agents attach to it as lanes. The cap is 8 attached agents; the ninth gets a refusal with the reason ("Too many agents are attached.") instead of a hang or a retry loop. Each lane may hold at most 8 open tabs, and the ninth tab_open fails with a limit error naming the limit. A second browser that tries to listen in the same place gets attach_in_use with a hint to close the first or change the runtime directory. When a lane disconnects its tabs go back to the person and their epochs advance, so queued work from that lane is refused rather than landing late.

Two things that made it hold up, both of which line up with your proposal:

• The admission decision and the refusal are the same operation, in the one process that owns the resource, so there is no window between "status says ready" and "launch" for two sessions to both squeeze through. Status is advisory in your design for the same reason; I would keep that.
• Every refusal is a code plus a hint about what to do next. The agents that handled it well were the ones that read the hint, not the ones with the best restraint instructions.

What we do not have, and your proposal does: a minimum launch interval, a runtime limit, and any hardware-health input. Our caps are counts only. If the freeze you saw turns out to be GPU mapping pressure rather than concurrency, a count cap like ours would not have saved you.