Product · Action lock

Freeze the page while the agent thinks.

Most agent runtimes let the page keep mutating mid-decision: timers fire, layouts reflow, network handlers run, JS heuristics observe the cursor. Action lock stops all of that at the docShell layer until the agent acts.

C++ docShell patchDefault onOff during navigation

What it freezes

Page.setActionLock({ enabled: true }) disables JavaScript on every frame via allowJavascript=false, then calls docShell.suspendPage(). That suspends the refresh driver, timers and intervals, network callbacks, and event handling. Layout reflows stop. Animations stop. Pointer events queue but do not fire.

JS execution

allowJavascript=false on every frame. No setTimeout, no Promise.then, no inline handlers.

Refresh driver

rAF callbacks, CSS animations, video playback all stop until the lock releases.

Network

In-flight responses queue but do not deliver to JS until the lock lifts.

Events

Pointer, keyboard, focus events suppressed. The page cannot observe the cursor mid-think.

Protocol

One protocol call in, one out. The lock is implicit on navigation — the next page loads without you asking.

// Before the agent decides
await page.send("Page.setActionLock", { enabled: true });
//   → JavaScript disabled on every frame
//   → docShell.suspendPage() halts the refresh driver
//   → timers, network callbacks, events queued

// After the agent commits an action
await page.send("Page.setActionLock", { enabled: false });
//   → page resumes immediately

// Navigation auto-releases — no need to flip the lock
await page.send("Page.navigate", { url: "https://example.com" });

Protocol · Page.setActionLock

Why this is impossible from a WebExtension

You cannot suspend the JavaScript event loop from JavaScript. Every existing "DOM freeze" library is best-effort and bypassable. Action lock patches nsDocShell in C++ so the page literally cannot run code until we say so. Navigation auto-releases the lock so the next page loads normally.

Resources

Architecture deep-dive
docs.vulpineos.com/architecture — every patch, where it lives, and why.
VulpineOS source
github.com/VulpineOS/VulpineOS — runtime, patches, additions.

Self-host the runtime today.

Pull the source, build the binary, and drive your first agent. The waitlist gates the managed runtime; the open-source path is open now.

Read the docs→Star on GitHub