OpenClaw Browser Agents Can Now See and Dismiss Modal Dialogs, Gateway Restarts Stop Orphaning Processes

Agents Can Finally Read the Dialog Box

Anyone who has tried to automate a web application knows the pain of modal dialogs. A JavaScript alert(), confirm(), or prompt() call freezes the page until someone handles it. For human users, that's a minor annoyance. For an AI agent trying to navigate a workflow, it's a brick wall — and until now, OpenClaw's managed browser didn't even tell the agent the wall existed.

The new dialog observation system changes that fundamentally. When a modal dialog appears during a browser action, the action response now includes a blockedByDialog flag along with the full dialog state under browserState.dialogs.pending. Each dialog gets a unique ID, so agents can target specific dialogs when multiple appear in sequence.

Responding is straightforward. An agent can accept a dialog with openclaw browser dialog --accept or dismiss one by ID with openclaw browser dialog --dismiss --dialog-id d1. Dialogs that get handled outside of OpenClaw — by user interaction or another automation layer — appear under browserState.dialogs.recent so the agent still has a record of what happened.

The feature comes with a security boundary. Dialog state is gated by the current URL policy, preventing agents from reading dialog content from pages they aren't authorized to access. This matters because dialog text can contain sensitive page content — a confirmation dialog might include account numbers, transaction amounts, or session tokens. Without URL-based gating, dialog observation would become a side channel for bypassing access controls.

Browser snapshots now include pending dialog state as well, giving agents a complete picture of the page even when they're not actively performing actions. For teams building browser-based workflows — form submissions, checkout flows, admin panels with confirmation gates — this is a meaningful step toward agents that can handle the messy reality of production web applications instead of only working on pages that never interrupt.

The Restart That Crashed the Server

Self-hosted OpenClaw deployments that use custom process supervisors — systemd, Docker, or lightweight alternatives on Raspberry Pi and VPS hardware — have been hitting a frustrating crash loop. The trigger: an ordinary gateway restart. Send a SIGUSR1 signal or apply a config patch, and the gateway would spawn a detached child process to handle the restart. The supervisor would lose track of the new PID. The old process would linger. The new one would try to bind the same port. EADDRINUSE.

The fix is elegant in its simplicity. Routine restarts now stay in-process by returning a “disabled” result, which triggers the run loop's existing in-process fallback. No new child process, no PID handoff, no supervisor confusion. Update restarts — the kind that require a fresh binary — still use the detach-and-respawn path through respawnGatewayProcessForUpdate, since those genuinely need a new process.

The documentation updates reflect the new behavior. Self-hosting guides for VPS and Raspberry Pi deployments now describe the OPENCLAW_NO_RESPAWN=1 environment variable more precisely: it keeps routine gateway restarts in-process, avoids extra process handoffs, and preserves PID tracking on resource-constrained hosts. The previous wording vaguely described it as avoiding “extra startup overhead,” which didn't convey the real benefit — or the real failure mode it prevents.

When Your Bot's Name Is Someone Else's Username

OpenClaw's Mantis system — the automated testing and proof framework that validates changes across Telegram, Discord, and other channels — has been using @Mantis and /mantis as trigger syntax in documentation and CI workflows. There's a problem with that: @Mantis is a real GitHub account belonging to a real person. Every time someone typed that trigger in a GitHub comment following the docs, they were inadvertently mentioning a stranger.

The fix standardizes all trigger references to @openclaw-mantis and /openclaw-mantis — the fully qualified bot name that OpenClaw actually owns. The change spans three documentation pages covering Mantis concepts, testing procedures, and Discord channel integration, plus three CI workflow files. Every example, every inline trigger, and every workflow dispatch reference now uses the namespaced form.

It's the kind of cleanup that seems trivial until you think about it from the other side. If your GitHub handle is @Mantis, you've been receiving notifications every time an OpenClaw contributor ran a test workflow. That stops now.

Documentation Changes at a Glance

Small Fixes, Compound Returns

None of Saturday's documentation updates are dramatic on their own. Dialog observation is a feature browsers have supported natively for years — OpenClaw is catching up to what Playwright and Puppeteer users already expect. The gateway restart fix addresses a failure mode that only appears under specific supervisor configurations. The Mantis rename is a courtesy fix with a search-and-replace implementation.

But each fills a gap that was silently costing users time. An agent stuck on an invisible dialog is an agent you have to babysit. A gateway that crash-loops after a config change is a deployment you learn not to touch. A bot name that pings an uninvolved stranger is a documentation standard nobody trusts. These are the kind of fixes that don't make headlines but make the difference between software you fight and software you forget is running.