# workflow-use: a recorded browser demonstration compiled into a replayable workflow slug: browser-use-workflow-use · https://miscsubjects.com/a/browser-use-workflow-use · category: reference · tags: reference, browser-automation, learned-flows · updated 2026-09-06T19:10:40.033Z browser-use/workflow-use (about 4,200 stars on 2026-09-06) records a human demonstration in the browser, has a model filter out the noise, and emits a JSON workflow file with variables extracted from form fields. It is the most on-point open-source repository for demonstration-to-executable-workflow. **The artifact.** `workflows/.workflow.json` plus an index, produced by a recorder. Variables are auto-extracted from forms so the same workflow runs with new inputs. **Execution.** Deterministic replay, with a documented fallback: steps that fail fall back to the browser-use agent. It runs from a CLI, a Python API and a local GUI. No native scheduler was found. **Maturity, in its own words.** The README states: "This project is in very early development so we don't recommend using this in production. Lots of things will change and we don't have a release schedule yet." **Why it matters here.** It shows the recorder-to-variables step working for browser actions, and it shows the gap the miscsubjects learned flow is aimed at: the recorded workflow is runnable but is not a member of a larger capability graph, cannot be scheduled from inside the project, and is not learned from an agent's own successful run. ## Sources 1. browser-use/workflow-use README — https://github.com/browser-use/workflow-use --- # browser-use: the browser-agent project whose profile model became the vocabulary slug: browser-use · https://miscsubjects.com/a/browser-use · category: reference · tags: reference, browser-automation · updated 2026-09-06T19:10:31.804Z browser-use (about 112,000 stars on 2026-09-06) is the largest open-source browser-agent project. An API-metered model drives a browser to complete tasks. It is not a web-model bridge and consumes model APIs, not subscriptions. It matters as the place where the ecosystem's session and profile vocabulary settled. **Profiles.** `BrowserProfile` carries `user_data_dir`, `profile_directory`, `storage_state`, `cdp_url` to attach to a running browser, `keep_alive`, headless and channel flags. The runtime layer is `BrowserSession` plus a `SessionManager` documented as "the SINGLE SOURCE OF TRUTH for all targets and sessions", synchronised from Chrome DevTools target events rather than polling. **Persistent authentication.** Two mechanisms that conflict: a persistent profile directory, and a storage-state JSON autosaved every thirty seconds by a watchdog. The code warns that passing both overwrites cookies in the profile. Most consequentially, browser-use will not drive a real Chrome profile in place: it copies the profile to a temporary directory on every start, and if Chrome's file locks block the copy it tells the user to close Chrome or attach over CDP instead. **Task state versus browser state.** Cleanly separated. Agent state, step count, file system state and conversation history are serialisable; browser state lives in the profile or storage state. **Reliability.** Thirteen watchdogs name the failure classes of long-running browser workers: crashes, hung requests, about:blank tabs, popups, captchas, downloads, permissions, security, DOM, local browser lifecycle, storage state, plus recording and network archives. **Why it matters here.** The miscsubjects browser worker adopted the split it demonstrates: the durable conversation record is canonical and the tab is disposable, and it seeds a dedicated profile from the owner's once instead of driving the owner's live profile. ## Sources 1. browser-use/browser-use source, session_manager.py — https://github.com/browser-use/browser-use --- # BrowserMCP: driving your own logged-in Chrome through MCP slug: browsermcp · https://miscsubjects.com/a/browsermcp · category: reference · tags: reference, browser-automation, mcp · updated 2026-09-06T19:10:29.496Z BrowserMCP (7,050 stars on 2026-09-06, last pushed April 2025) is a TypeScript MCP server that drives the user's own Chrome through a companion extension over a local WebSocket. It is a fork of Microsoft's playwright-mcp rewired for a real, logged-in browser. It is not a web-model bridge and knows nothing about any model; it is included because it is the most-starred project in the adjacent space and is often miscited as one. **What it exposes.** Twelve generic tools: navigate, go back and forward, snapshot, click, hover, type, select option, press key, wait, get console logs, screenshot. Elements are addressed by references from an accessibility snapshot produced by the extension, not by CSS selectors. **Sessions.** One mutable WebSocket handle. A new connection closes the previous one, so there is one connected tab per process, last writer wins, with a flat thirty-second tool timeout. **Its pitch.** The README lists "Logged In: Uses your existing browser profile, keeping you logged into all your services." and "Stealth: Avoids basic bot detection and CAPTCHAs by using your real browser fingerprint." Nothing about substituting a subscription for API metering. **What cannot be verified.** The repository depends on unpublished workspace packages and the extension is not in it, so its selector and snapshot mechanics are unknown from public source. **Why it matters here.** It proves demand for controlling a logged-in browser through MCP and shows the simplest possible session model. The miscsubjects gateway deliberately does not expose generic browser control through any public capability; only bounded browser-model verbs cross the tunnel. ## Sources 1. BrowserMCP/mcp README — https://github.com/BrowserMCP/mcp --- # Skyvern code caching slug: skyvern-code-caching · https://miscsubjects.com/a/skyvern-code-caching · category: reference · tags: reference, browser-automation, learned-flows · updated 2026-09-06T19:09:52.462Z Skyvern (about 22,900 stars on 2026-09-06) is an open-source and commercial browser-automation platform whose workflows are declarative block graphs. Its code caching feature is the strongest shipping example of a successful agent run becoming an executable artifact. **What it records.** After a run with the agent, Skyvern records the full action sequence the agent took, clicks, form fills, extractions and navigation, and generates executable code from it, cached per workflow block so partial reuse works. **How it executes later.** A subsequent run can pass `run_with="code"` and the cached script replays with no screenshots and no model inference. The documentation describes this as deterministic and three to five times faster, up to about seventy percent cheaper. If the cached code hits a layout change, Skyvern re-runs the agent and regenerates the cache. Conditional, wait and code blocks always execute live. **Where it sits.** Workflows are first-class objects with an API and can be scheduled; the docs recommend pairing cached code with scheduled agents for recurring runs. Whether a cached script is addressable outside a Skyvern run is unknown. **Why it matters here.** In the survey of trace-to-workflow systems it is the only production system spanning three links of the chain: a trace-derived executable, attached to a workflow object, with an API and a schedule. The miscsubjects learned flow makes the same move at a different grain, compiling the ordered capability calls of a receipted run into a flow row rather than browser actions into a script, and adds the fourth link, that the compiled row is itself an ordinary capability another flow can call. ## Sources 1. Skyvern docs: Code Caching — https://www.skyvern.com/docs/developers/features/code-caching.md --- # graph-memory browser-mcp slug: graph-memory-browser-mcp · https://miscsubjects.com/a/graph-memory-browser-mcp · category: reference · tags: reference, browser-automation, mcp · updated 2026-09-06T19:09:47.394Z graph-memory/browser-mcp (4 stars on 2026-09-06, last pushed August 2026) is a TypeScript browser daemon, Playwright-driven, headless by default, exposing thirty-six generic browser tools through both MCP and REST. It has about three thousand lines of source and nine thousand lines of tests. It is not a web-model bridge; it is the best reference implementation in this space for three things a bridge needs. **Profiles and sessions.** A profile is a named on-disk Chromium user-data directory. A browser manager owns one context per profile. A browser session is a per-client view over a shared manager: several MCP clients on one profile share the login state but keep their own active tab. The code's own comment states the invariant: "Multiple MCP sessions on the same profile share one BrowserContext (so a login in one is visible in another), but each session keeps its OWN active tab." Cookies and local storage survive restarts because the profile is on disk. **Network capture.** A capped ring of network entries and a smaller ring of response bodies are exposed as tools, plus a console ring. **One registry, two projections.** The same tool registry with the same schemas is served over MCP and over REST at `/api/v1/tools/{name}`, with a generated OpenAPI document. This is a callable surface, not workflow participation: the repository has no scheduler, event intake or workflow engine. **Security posture worth copying.** It refuses to bind to a non-loopback address without an API key, because, in its words, "/mcp can automate a real browser on behalf of anyone who can reach it." **Why it matters here.** Its session and profile model and its network-body capture are the patterns the miscsubjects browser worker follows: a dedicated persistent profile, one CDP connection, per-session pages, and the provider's own response stream as the primary completion signal. ## Sources 1. graph-memory/browser-mcp source — https://github.com/graph-memory/browser-mcp