# platform-imessage: Beeper's Swift library that drives the Messages app through Accessibility

slug: platform-imessage · https://miscsubjects.com/a/platform-imessage · category: reference · tags: reference, imessage, mac, messaging, accessibility · updated 2026-09-08T20:13:35.726Z

platform-imessage is an open-source Swift library and command-line program from Beeper, the multi-network chat company, that automates the Messages app on a Mac. Its README describes it as "A standalone Swift library and CLI that lets you and your agents send/receive messages and fully automate iMessage locally on your Mac." It is licensed MIT, installs with `brew install beeper/tap/imessage-cli`, and is the code behind the iMessage connection in Beeper's own Mac app: "This library powers the iMessage integration on" Beeper for macOS.

**Two mechanisms, one program.** For reading, it opens the Messages database (`~/Library/Messages/chat.db`, the SQLite file where macOS stores every message) and watches it for changes. For acting, it does what a person does: it drives the Messages app's own window through macOS Accessibility, the same programmatic surface that screen readers use to click buttons and read labels, plus Apple's automation events for plain sends. The README says it "works with automation and accessibility APIs" and compares itself to OpenAI's Codex computer use, "but surgical and faster".

**Why that matters.** Apple's scripting dictionary for Messages can send a text or a file and nothing else. Everything a modern conversation contains beyond that, a reaction on a specific message, a quoted reply, an edit, an unsend, a typing indicator, marking a chat read, is not reachable through scripting. The other established route to those features, BlueBubbles, reaches them through a Private API helper that only loads when System Integrity Protection is off; the README's feature table marks each of those rows and footnotes them: "BlueBubbles supports this through its Private API helper, which requires disabling SIP." platform-imessage reaches the same rows with SIP on, by operating the real window.

**What the command line does.** `chats`, `chat`, `messages`, `message`, `search` read history with contact-resolved names, tapbacks, stickers, mentions, replies and edit history. `send` and `send-file` send to an address or an existing chat; `create-chat` starts a new direct or group chat with people never messaged before. `reply` and `reply-file` send quoted replies to a message id (or to `latest`, `latest-1`). `react` and `unreact` add or remove a tapback on any message by id, including arbitrary emoji. `edit` and `undo-send` change or retract a sent message inside Apple's time windows. `typing` turns the typing indicator on or off; `mark-read`, `mark-unread`, `mute`, `unmute`, `notify-anyway` and `delete-chat` manage a chat; `activity-status` reports whether the other party is typing and their Do Not Disturb state; `load-attachment` forces an offloaded attachment to download. `start-watching` streams database changes as events. Output is YAML by default and JSON with `--json`.

**How it avoids fighting the person at the keyboard.** By default it launches a secondary instance of the Messages app and drives that window, so the primary window a person is using is left alone. The flag `--no-use-secondary-instance` turns that off.

**Permissions and limits.** Four macOS grants: Accessibility, Contacts (optional, for names), Messages data (Full Disk Access) and Automation for Messages. The README states what it will not do: "expose more features if you disable SIP, allow automating multiple iMessage accounts, work on Windows/Linux". Group management (rename, add or remove members, leave, photo) and rich sends (effects, subjects, captions) are listed as planned. Only one process may drive the Messages app at a time. There is no HTTP server, no webhook and no push relay; the README's table gives that row to BlueBubbles.

**Fragility.** Because acting means locating message cells in a live window, a macOS release that rearranges the Messages interface can break an action until the library is updated; the project's todo list tracks such fixes per macOS version. Reading is not affected by that, since it comes from the database.

**Verdict.** On a Mac with SIP on, platform-imessage is the only maintained program that reaches reactions on arbitrary messages, quoted replies, edits, unsends, typing and read state. Its cost is the Accessibility route: slower than a database read, dependent on the window layout, and exclusive of any other automation touching the Messages app at the same moment.


## Sources

1. beeper/platform-imessage README — https://github.com/beeper/platform-imessage
2. beeper/platform-imessage README, feature table footnote — https://github.com/beeper/platform-imessage#features


---

# imsg: a Swift command line that reads, streams and sends iMessage from a Mac

slug: imsg · https://miscsubjects.com/a/imsg · category: reference · tags: reference, imessage, mac, messaging · updated 2026-09-08T20:13:06.672Z

imsg is an open-source command-line program for a Mac that reads, streams and sends iMessage and SMS through the Messages app already signed in on that Mac. Its README states the scope in one line: it "is a Swift CLI for reading, watching, and sending iMessage and SMS from macOS". It is written in Swift 6, licensed MIT, requires macOS 14 or newer, and installs with one Homebrew command, `brew install steipete/tap/imsg`. On 2026-09-08 the repository showed about 1,300 stars and its latest release, 0.15.3, was published the day before.

**Where the messages come from.** Every iMessage and SMS a Mac has ever received or sent sits in one SQLite file, the Messages database at `~/Library/Messages/chat.db`. imsg opens that file directly. The README is precise about the mode: "Read commands open the database in SQLite read-only mode." Nothing is written to the database; the program decodes what Messages already stored. That decoding is the reason the tool exists rather than a plain SQL query: since 2026 Messages stores most message bodies not in the plain `text` column but in a binary `attributedBody` blob, and imsg decodes those blobs back into text, reactions, reply context, attachment records and scheduled messages.

**Streaming.** The `watch` command emits one JSON object per new message as it arrives. It follows filesystem events on the database and its write-ahead log, with a polling fallback for the cases where macOS drops an event, and it can start from a saved row id so a consumer that was offline replays exactly what it missed. Output discipline is explicit: the flag "emits one JSON object per line. Human progress and warnings stay on stderr, so stdout remains safe to stream."

**Sending.** `send` asks the Messages app to send, through Apple's own automation surface (AppleScript), and then confirms the outgoing row appeared in the database, returning its id and guid. A separate `message.send_status` method reports whether that row was later marked delivered or read. Text, files and audio go through the same path. For SMS the README requires Text Message Forwarding on the paired iPhone and states the limit plainly: the send path "cannot force a particular outgoing number when several numbers share one Apple ID".

**A long-running interface for programs.** `imsg rpc` speaks JSON-RPC 2.0 over standard input and output, with no network port: initialize, chats.list, messages.history, messages.search, messages.after (a cursor over everything newer than a row id), messages.stats, watch.subscribe, send, send.tracked (idempotent, caller-supplied id), message.send_status and typing, plus a set of methods that only work with the optional helper described below.

**Permissions.** Three macOS grants govern what works. "Full Disk Access is required for local database reads." Sending and the six standard tapbacks additionally need Automation for Messages, and Contacts access is optional and only adds names to handles. Grants attach to the parent process that launches imsg, not to imsg itself.

**The two tiers.** Everything above runs with System Integrity Protection on. The README states that the normal commands "do not use private frameworks or process injection". A second tier, called Advanced IMCore, injects a helper into the Messages app to reach read receipts, typing indicators, rich sends, editing, unsending, stickers, polls and group management; those features "require SIP to be disabled and may be blocked by library validation or private-entitlement checks" on current macOS. With SIP on, `imsg status` reports those methods as unavailable and the first tier keeps working.

**What it does not do.** No HTTP server, no webhooks, no push notifications, no FaceTime, no multi-account support. Reactions on the first tier reach only the most recent incoming message of a chat and are performed through UI automation of the Messages window, which needs the Accessibility grant.

**Verdict.** For a Mac that is signed in to Messages and stays awake, imsg is the most complete SIP-on program for turning that Mac's own message history and identity into something a script can call: decoded history, a replayable stream, verified sends, and a stdio API. Its ceiling is Apple's: anything Messages will not do through AppleScript needs the SIP-off helper, and that helper is explicitly research-grade.


## Sources

1. openclaw/imsg README — https://github.com/openclaw/imsg
2. openclaw/imsg README, Permissions and Advanced IMCore — https://github.com/openclaw/imsg#permissions


---

# 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/<id>.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


---

# ChatGPT-Web2API: a logged-in ChatGPT session served as an OpenAI-compatible API

slug: chatgpt-web2api · https://miscsubjects.com/a/chatgpt-web2api · category: reference · tags: reference, browser-models · updated 2026-09-06T19:10:38.063Z

Octo-Lex/ChatGPT-Web2API (43 stars on 2026-09-06, created June 2026) is a Python project of about seventeen thousand lines that turns a logged-in ChatGPT web session into an OpenAI-compatible REST API with streaming, plus an MCP server with sixteen tools. It has a small audience and the most technically correct completion detection of any project read.

**Sessions.** Real ChatGPT conversation ids. A request may name a conversation id and the driver navigates to it; tools list, get, archive and delete conversations and manage projects and memories. It creates and resumes real provider conversations.

**Completion.** Hybrid, with the provider's own signal first. Its detector reads the backend's end-of-turn flag by running a fetch against ChatGPT's own backend API from inside the page, with the page's own access token, and falls back to the per-turn action button in the DOM, with a stall detector that raises a named error.

**Its pitch.** The most explicit in the set: "Turn ChatGPT into an API. No API key. No token extraction. No sentinel solving." and a cost table listing the browser route as free because it uses the subscription.

**Limits it states itself.** Single vendor. The web model cannot call tools. Per-client tab isolation inside one SSE process is documented as unfinished.

**Why it matters here.** It demonstrates the strongest completion signal available for ChatGPT, the provider's own end-of-turn marker read in page context. The miscsubjects adapters use the end of the provider's streaming response observed at the network layer as the primary signal, which is the same idea observed from outside the page rather than inside it.

## Sources

1. Octo-Lex/ChatGPT-Web2API README — https://github.com/Octo-Lex/ChatGPT-Web2API


---

# agentify desktop: six web models behind one selector file and a rate governor

slug: agentify-desktop · https://miscsubjects.com/a/agentify-desktop · category: reference · tags: reference, browser-models, mcp · updated 2026-09-06T19:10:35.912Z

agentify-sh/desktop (549 stars on 2026-09-06, created January 2026) is an Electron control centre that lets coding agents such as Codex, Claude Code and OpenCode drive logged-in ChatGPT, Claude, Gemini, AI Studio, Grok and Perplexity through MCP. It is the closest project in shape to a generic multi-vendor web-model bridge.

**Vendors as data.** Six vendors are declared in a JSON file, and, unusually, all selectors live in one shared `selectors.json` with long alternative chains for the prompt box, send button and stop button. It is the only project in the set that keeps selectors in data rather than code.

**Completion.** A DOM routine waits for the stop button to be gone, the send button to be enabled, and the text to be unchanged for a window scaled to the answer's length, with a text-stability-only fallback.

**Surfaces.** Twenty-seven MCP tools and a local bearer-token HTTP API.

**Concurrency.** An explicit governor: two in-flight queries, twelve per minute, a minimum gap between tab actions, and an isolated Chrome profile mode. It is the only rate governor found in this space.

**Its pitch.** The README says it "lets MCP-capable tools such as Codex, Claude Code, and OpenCode use the AI subscriptions you are already signed into, while keeping browser state, files, and automation on your machine."

**What is missing.** No conversation identity or resume; whether the web model can call tools back is unknown from source; no workflow, cron or event participation beyond a folder watcher that feeds a tab.

**Why it matters here.** Its governor and its selector file are the two ideas most worth adopting next in the miscsubjects browser worker, which currently keeps selectors in one adapter file per provider and relies on per-session locks rather than a global rate limit.

## Sources

1. agentify-sh/desktop README — https://github.com/agentify-sh/desktop


---

# codex-chatgpt-web: ChatGPT Web served to Codex as a native model

slug: codex-chatgpt-web · https://miscsubjects.com/a/codex-chatgpt-web · category: reference · tags: reference, browser-models, mcp · updated 2026-09-06T19:10:34.089Z

codex-chatgpt-web by miuuyy (5,023 stars on 2026-09-06, created July 2026) is the one project in the browser-model space with real adoption. It presents ChatGPT Web, including the Pro tier, as a native model inside OpenAI's Codex app by serving a local Responses API backed by an embedded-browser ChatGPT Temporary Chat. It is about thirty-two thousand lines of TypeScript with more than forty test files.

**Sessions.** Task-bound. Sequential messages reuse one Temporary Chat under a conversation key with a per-turn lease. At the context boundary a retained agent writes a checkpoint before a clean chat starts, with tests for rolling checkpoints and compaction.

**Completion.** A DOM observer keyed on ChatGPT's revision attributes, reporting whether the copy-turn action is visible and the stop button gone. All selectors live in one file, the cleanest selector layering found.

**Tools.** Not prompt-and-scrape. It runs a real MCP server and registers it as a ChatGPT connector over an OpenAI tunnel, so ChatGPT's own server-side agent loop calls the tools natively, scoped by a per-turn capability token retired at settlement.

**Its pitch.** The README badge reads "Free AI with no API fees" and the title promises use "beyond Codex usage limits". It is also candid that Temporary Chat "is a ChatGPT privacy mode, not anonymity or local-only inference" and that the project is unofficial.

**Why it matters here.** It shows what robust looks like for one host and one provider: real conversation continuity, a structured completion signal, and the vendor's native tool protocol. The miscsubjects gateway trades that depth for breadth, five vendors behind one contract, and for participation in a capability graph rather than one editor.

## Sources

1. miuuyy/codex-chatgpt-web README — https://github.com/miuuyy/codex-chatgpt-web


---

# 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


---

# mcp-web-llm: six logged-in web models exposed as MCP tools

slug: mcp-web-llm · https://miscsubjects.com/a/mcp-web-llm · category: reference · tags: reference, browser-models, mcp · updated 2026-09-06T19:10:26.349Z

mcp-web-llm is a small open-source project (9 stars on 2026-09-06, created March 2026, last pushed April 2026) that turns six logged-in web chat products into MCP tools. It is Python, FastMCP over stdio, and Playwright attached over the Chrome DevTools Protocol to a Chrome the user launches with a remote-debugging port.

**What it does.** Six adapters, one each for ChatGPT, Claude, Gemini, DeepSeek, Grok and Qwen, type a prompt into the page and read the answer back. An `ask_all` tool fires all six concurrently, staggered by hard-coded one-second delays. Files and images can be uploaded. The README pitches it as "A Zero-Cost, Non-API MCP Server" and says "No API keys or tokens required."

**How it detects completion.** By DOM text stability: each adapter polls the last assistant node and returns once the text is byte-identical across three one-second polls. On timeout it returns the literal string "Timeout. Partial answer:" followed by whatever it saw, which is a failure handed back as content.

**Sessions.** There is no session object. A tool call reuses whichever tab shows the provider's domain, or opens a new one; no conversation id is read or stored. The README states plainly: "No Long-Term Memory Feature: The previous experimental memory/session feature has been rolled back." A SQLite history file is written and never read.

**What it does not do.** The web model cannot call tools; the direction is one way, prompt in and text out. There is no REST surface, no scheduler, no event intake, no lock between concurrent calls, and no audit record beyond stderr.

**Why it matters here.** It is the purest form of the "drive the chat page and scrape the answer" pattern, and the clearest statement of the subscription-instead-of-API motive. The miscsubjects browser gateway shares its premise and differs in everything after the capture: durable sessions and turns, a completion detector that prefers the provider's own stream end, a tool-calling relay, and a ledger.

## Sources

1. HGD-coder/mcp-web-llm README — https://github.com/HGD-coder/mcp-web-llm


---

# OpenClaw self-learning

slug: openclaw-self-learning · https://miscsubjects.com/a/openclaw-self-learning · category: reference · tags: reference, agents, learned-flows · updated 2026-09-06T19:09:56.460Z

OpenClaw (389,023 stars and 81,740 forks on 2026-09-06, version 2026.9.2 at commit 45cbffc) is a personal agent gateway: sessions, channels, tools, skills and automations behind one control plane. This reference covers one part, the self-learning system, read at source.

**What is learned.** A `SKILL.md` file: Markdown instructions with YAML frontmatter carrying a name and description, stored under the agent's workshop-skills directory. Not tool schemas, not executable code, not a recorded trajectory, not a workflow graph. The reviewer prompt that produces it asks for "a stable procedure that saves at least two future model round trips" and for "reusable steps and decision rules, not incident narratives." Support files may include scripts stored as text, but nothing runs them automatically.

**What the reviewer reads.** A detached copy of the run's model context plus a receipt of the skills actually used. OpenClaw has a real trajectory recorder that writes JSON Lines traces, but no learning path consumes it.

**How a learned skill executes later.** The agent re-reads the instructions and reasons through them again. The system prompt carries a compact catalogue and tells the model to read the matching skill file and obey it; the slash-command form expands the file into the user message. There is no replay, no compiled workflow and no generated code path. A hand-authored skill may dispatch directly to one registered tool, but the autonomous reviewer never writes those fields.

**Lifecycle and gates.** Proposals move pending, applied, rejected, quarantined or stale. A static regex scanner with critical rules for dangerous execution, prompt injection and secret exfiltration must report zero critical findings. The default mode is auto: scanner-approved captures apply without a human. Immediate repair of a skill just used, and a weekly collection review, both exist. Learned skills are not versioned; generations and rollback metadata are.

**Automations.** Separate from skills. Cron runs messages, commands and scripts on schedules.

**Why it matters here.** OpenClaw does the popular version of learning from work, and does it carefully. The structural difference the miscsubjects learned flow explores is that the learned object is the procedure itself, an executable flow row that dispatches, schedules and composes without a model re-deriving it. Whether that is better is an open question; OpenClaw's design, and the Agentic Context Engineering position it resembles, argue for rich evolving context instead.

## Sources

1. OpenClaw docs: self-learning — https://github.com/openclaw/openclaw/blob/main/docs/tools/self-learning.md


---

# Agent Workflow Memory

slug: agent-workflow-memory · https://miscsubjects.com/a/agent-workflow-memory · category: reference · tags: reference, research, learned-flows · updated 2026-09-06T19:09:54.817Z

Agent Workflow Memory, from Zora Zhiruo Wang and collaborators at Carnegie Mellon (arXiv 2409.07429, ICML 2025, 467 stars on 2026-09-06), is the most-cited anchor of the research line that induces reusable workflows from agent experience.

**What is learned.** Natural-language abstracted action templates, called workflows, stored in a workflow library. They can be induced offline from training examples or online from the agent's own test-time trajectories.

**How it is used.** The workflows are selected and injected back into the agent's prompt. They are text re-read as context, not executable code and not callable units.

**Results reported.** Relative success-rate improvements of 24.6 percent on Mind2Web and 51.1 percent on WebArena, with fewer steps.

**Where the field went next.** The same author cluster followed with programmatic skill induction, in which successful episodes are abstracted into callable Python functions with programmatic verification, reporting further gains over text skills. Later 2026 papers distil parameterised finite-state subgraphs from traces and compile them into callable skills. None of these has a public scheduling or composition story.

**Why it matters here.** It is the clearest statement of the text-artifact position that OpenClaw skills, Claude Skills and Codex Record and Replay also take: learn instructions, let a model re-derive the procedure. The miscsubjects learned flow takes the other position, learn the procedure as an executable object, and this reference exists so that the article comparing the two names the strongest version of the one it argues against.

## Sources

1. Agent Workflow Memory, arXiv 2409.07429 — https://arxiv.org/abs/2409.07429


---

# 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


---

# MCP-WebLLM (MCP Multi Bridge)

slug: mcp-webllm · https://miscsubjects.com/a/mcp-webllm · category: reference · tags: reference, browser-models, mcp · updated 2026-09-06T19:09:43.410Z

MCP-WebLLM, published as "MCP Multi Bridge" by luskB (58 stars on 2026-09-06), is a Manifest V3 Chrome extension that gives web chat products access to local MCP servers. It runs the opposite direction from mcp-web-llm: it does not expose the web model to anything, it is an MCP client injected into the chat page.

**How it works.** The extension renders each selected MCP server's tools as a Markdown manifest and pastes it into the conversation, or attaches it as a file. The model is instructed to request a call by writing a fenced JSONL block. A MutationObserver on the page, debounced 300 milliseconds with a two-second interval as backstop, scans code blocks for `function_call_start` and `function_call_end`, parses them with a JSONL pass and a brace-depth state machine, executes the call through the service worker over SSE, streamable HTTP or Chrome native messaging, and injects the result back into the composer, optionally pressing send. Errors are fed back deliberately so the model can repair its parameters.

**Sessions and state.** None for the conversation. Server configurations and "skills", which are Markdown pasted into the prompt, live in extension storage.

**The agent loop.** There is no loop in code. An "Agent Mode" section in the injected manifest tells the model to keep calling tools until done. There is no iteration or depth cap; the only caps are transport retries and the auto-send debounce.

**Why it matters here.** It is the closest precedent for the relay lane in the miscsubjects gateway, and proof that a web model with no native tool calling can operate external tools if something outside the tab parses its text and answers it. The gateway's relay differs by living outside the browser, by parsing with the build's own tag grammar, by running each call under the caller's scoped authority, by bounding iterations, and by receipting every call.

## Sources

1. luskB/MCP-WebLLM README — https://github.com/luskB/MCP-WebLLM


---

# The second brain register: who built the plain-text knowledge base, and which part of it lasts

slug: second-brain-register · https://miscsubjects.com/a/second-brain-register · category: systems · tags: second-brain, obsidian, markdown, knowledge-graph, reference, zettelkasten · updated 2026-08-06T07:20:07.306Z

This is a register of the people, formats and programs that built the idea of a personal knowledge base out of plain text files. It exists to be tracked rather than read once: when someone in this field publishes something that changes the shape of the problem, the entry for them is where it goes.

It is organised by what each entry actually contributed, because the field has a habit of crediting tools for ideas and ideas for tools. The formats outlast the apps. The apps outlast the methods. Most of the methods are the same three ideas in different packaging.

One correction first, because it is the thing people get wrong in their first hour.

## The syntax is two brackets, not three

A link between two notes is written with two square brackets on each side.

    [[bpc-157]]

Obsidian's own documentation lists that as the wikilink format. Two more forms matter. A pipe changes what the reader sees while leaving the target intact:

    [[bpc-157|the compound itself]]

And a hash points at a heading inside the target:

    [[the-obedience-gap#Part III]]

Three brackets is not a syntax. It is what people remember after seeing `[[ ]]` once, and it silently fails to link, which is the worst kind of mistake: the note looks written and the graph stays empty.

---

## The lineage

### Niklas Luhmann — the slip box, and the reason links come before folders

A German sociologist who worked from a physical card index for decades and published at a rate that made people ask how. The answer was in the box: each card carried one idea, a fixed identifier, and pointers to other cards. Ideas were retrieved by following links, not by remembering which drawer they were in.

The load-bearing part is not the cards. It is that **the address of a note is permanent and its position is not**. Every good system since has re-derived that rule, and every bad one has tried to replace it with a better folder hierarchy.

**Track:** the secondary literature; his own archive has been digitised and published by Bielefeld University.

### Sönke Ahrens — the method, written down

*How to Take Smart Notes* is the book that turned Luhmann's practice into something a person could follow, and it is the source most later systems are quietly restating. Its useful contribution is the separation of note types: fleeting capture, literature notes tied to a source, and permanent notes written in your own words. The distinction between "I saved this" and "I understood this" is the whole discipline.

**Track:** the book. There is a revised edition.

### Andy Matuschak — evergreen notes

The most rigorous thinking in the field, published as a working note site rather than a book. His definition: "*Evergreen notes* are written and organized to evolve, contribute, and accumulate over time, across projects."

Three principles follow, stated as titles of their own notes: "Evergreen notes should be atomic", "Evergreen notes should be concept-oriented", and "Evergreen notes should be densely linked".

Those three lines are the best available specification for what a note in a knowledge base should be, and they map directly onto machine operations. Atomic means one addressable claim. Concept-oriented means the title is the assertion. Densely linked means the graph is the product, not a visualisation of it.

**Track:** notes.andymatuschak.org. It updates in place, which is the point.

### Tiago Forte — the name, and PARA

The person who made "second brain" a category. His organisational scheme, PARA, is described in his own words as "a simple, comprehensive, yet extremely flexible system for organizing any type of digital information across any platform": Projects, Areas, Resources, Archives.

PARA is a folder scheme, and its honest reading is that it solves *actionability*, not knowledge. It sorts by how soon you need something. That is genuinely useful for work and close to useless for a corpus of research, where the same article is needed at unpredictable times forever. Take the vocabulary, notice what it optimises for, and do not adopt it as a taxonomy for a reference library.

**Track:** fortelabs.com. High output, commercially framed.

### Nick Milo — maps of content

The idea worth having from this corner: when a subject accumulates enough notes, you write a note whose job is to be a curated index of them, by hand, with the links in a deliberate order. A map of content is an authored entry point, not a generated one.

Generated indexes and authored maps are different objects and a good system has both. This site's ranked write-next queue is the generated kind; a map of content is the human kind.

**Track:** Linking Your Thinking.

### Maggie Appleton — the digital garden

The clearest articulation of publishing notes in an unfinished state, with the growth stage stated openly rather than implied. The relevant discipline is that a page declares its own confidence — seedling, budding, evergreen — so a reader knows what they are holding. Any system that publishes work in progress needs some version of this, or every page reads as a finished claim.

**Track:** maggieappleton.com.

---

## The formats — the layer that actually survives

Apps get acquired and shut down. Methods go out of fashion. A file format with a specification and multiple implementations is the only part of this field you can build on for a decade.

### CommonMark, and GitHub Flavored Markdown

Markdown had no precise specification for years, so every implementation disagreed at the edges. CommonMark is the formal one; GFM is the widely-implemented superset that adds tables, task lists and strikethrough. Anything intended to be portable should target CommonMark plus the specific GFM extensions it actually needs, and should say which.

### YAML frontmatter

A block of key–value metadata at the top of a Markdown file, delimited by `---`. It came from static site generators and became the universal way to attach properties to a note. Its real limitation matters for design: nested structures are awkward to edit and awkward to validate. Keep frontmatter flat — identifier, revision, hash, slug, tags, dates — and put anything structured in a sibling file.

### JSON Canvas

The most underrated entry here. Obsidian's canvas files are an open format, JSON Canvas 1.0, published 11 March 2024. In its own words, it "was created to provide longevity, readability, interoperability, and extensibility to data created with infinite canvas apps."

The whole spec is two optional top-level arrays — `nodes` and `edges` — with four node types: `text`, `file`, `link`, and `group`. That is small enough to generate from a link graph with no library and no layout engine. If you already hold edges, you can write a canvas.

### Obsidian Bases

A core plugin since Obsidian 1.9.0 on 21 May 2025, and the important thing is the file: a `.base` is plain YAML with `filters`, `formulas`, `properties`, `summaries` and `views`. A filter looks like this:

    filters:
      or:
        - file.hasTag("tag")
        - and:
            - file.hasTag("book")
            - file.hasLink("Textbook")

That means a saved query over a corpus is a text file a build can generate and a reader opens as a live table in their own app. It replaces the plugin that used to own this job.

### Zettelkasten identifiers, and Johnny Decimal

Two competing answers to naming. Zettelkasten practice uses an opaque permanent identifier, usually a timestamp, so the name never has to change. Johnny Decimal uses a strict numeric hierarchy so a human can hold the whole map in their head.

They are in genuine tension and the resolution is to use both for different things: an opaque identifier as the durable identity, a readable path as the projection. If the readable name is the identity, renaming breaks links.

---

## The programs

### Obsidian

Created by Shida Li and Erica Xu; first beta 30 March 2020, version 1.0.0 on 13 October 2022. Local Markdown files in a folder called a vault. Canvas arrived December 2022; Bases in 2025.

It is the right compatibility target for one structural reason, and it is not popularity: **there is no container to reverse-engineer.** A vault is files on a disk. Anything that can write Markdown and folders can produce one, and anything that can read them can consume one. The graph view, backlinks, properties and canvas are all derived from the files.

### Roam Research

The product that made bidirectional linking a mainstream expectation and, for a period, set the agenda the whole field responded to. Block-level references were its distinctive idea: the addressable unit is a paragraph, not a page. Its cautionary contribution is equally real — it was cloud-first, and the difficulty people had getting their material out of it is the strongest argument in this entire register for plain files on your own disk.

### Logseq

Open source, outliner-first, operating on local Markdown files. The main alternative for people who want blocks as the primary unit but not a hosted service.

### org-mode and org-roam

Emacs. Predates most of this field by decades and does more than any of it — notes, tasks, literate code, exported documents — in one plain-text format that is not Markdown. If you already live in Emacs it is the most powerful option available; if you do not, its format will not travel to the rest of these tools without conversion.

### TiddlyWiki

A self-contained wiki in a single HTML file, by Jeremy Ruston, and far older than the current wave. Worth knowing because it solved portability in the most literal way anyone has: the notes and the application are one file you can email.

### Dendron, Foam

Editor-native approaches. Foam builds a linked notes workflow inside VS Code; Dendron pursued hierarchical naming as the organising primitive. Both matter chiefly as evidence that wikilinks and backlinks are not an Obsidian feature — they are a pattern that reappears in any editor.

### Anytype, Tana, Capacities, Heptabase, Reflect

The current generation, each betting on a different primitive: local-first objects, supertags and structured queries, typed objects, spatial whiteboards, speed with AI assistance. Track them for ideas rather than as targets. None has an open format on the level of Markdown-in-folders, so exporting *to* them is a commitment and exporting *from* them is a risk.

### Zettlr, Joplin, SilverBullet, Athens

Also-rans and specialists worth one line each: Zettlr is academic-writing-first with citation support; Joplin is a sync-and-encryption-first notebook; SilverBullet is a self-hosted programmable notebook; Athens was an open-source Roam alternative that stopped. Athens is in the register because a dead project is a data point about which bets do not pay.

---

## The publishers

Turning a vault into a website is a solved problem with several good answers, and it matters here because the reverse direction — a website that emits a vault — is the same graph read the other way.

**Quartz**, by Jacky Zhao, is the strongest of them: "Quartz is a fast, batteries-included static-site generator that transforms Markdown content into fully functional websites", with full-text search, a graph view and Obsidian compatibility. Currently at v5.

**Obsidian Publish** is the first-party paid option. **Eleventy**, **Hugo** and **Astro** are general static site generators that people point at vaults with varying amounts of glue.

The thing to notice: every one of these treats the folder of Markdown as canonical and the site as the projection. This site runs that arrangement in reverse — the database owns identity and the folder is generated — which is a defensible choice, but it means the burden of proving a round trip is lossless sits here rather than with the tool.

---

## The Obsidian plugin layer, narrowed

The community plugin ecosystem is in the thousands and almost all of it is irrelevant to a build. These are the ones whose *ideas* are worth knowing, since the features either exist natively now or are worth reimplementing:

- **Dataview** — queries over frontmatter as if the vault were a database. This is the idea Bases has now absorbed into core, and its long popularity is the evidence that structured metadata is the feature people actually wanted.
- **Templater** — templates with logic, which is how a "new article of this kind" gesture becomes repeatable.
- **Excalidraw** — hand-drawn diagrams stored inside the vault rather than in a separate service.
- **Obsidian Git** — version control over the vault, which is what makes a vault a synchronisable artifact rather than a folder that hopefully still matches.
- **Smart Connections** — embedding-based related-note suggestions, i.e. semantic edges as a complement to authored ones.

The pattern worth extracting: the plugins that lasted all added *structure* over the same plain files. None of them added a new storage format.

---

## The LLM-era entries

### Karpathy's llm-wiki

Published as a GitHub gist in April 2026 and the most consequential recent entry in this register. It opens: "A pattern for building personal knowledge bases using LLMs. This is an idea file, it is designed to be copy pasted to your own LLM Agent."

The architecture is three layers — immutable raw sources, a wiki of model-written Markdown, and a schema file (`CLAUDE.md` or `AGENTS.md`) that tells the agent the rules — plus an `index.md` catalogue and a `log.md` history.

The argument is a direct attack on retrieval-per-query: instead of re-reading raw sources each time, the model compiles them once into a persistent interlinked wiki, because "the wiki is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged."

Two things to note about it precisely, because both get misreported. It is a one-page idea file, not software. And it does use the phrase — it ends by telling you to open a local server and "start building your second brain."

**Track:** the gist, and the re-implementations. There are many; most add a runner and lose the point.

### Model Context Protocol servers over vaults

The mechanism by which an agent reads and writes a vault directly rather than being handed pasted text. Several Obsidian MCP servers exist. This is the layer to watch, because it determines whether "the model organises my notes" means a real filesystem operation or a chat transcript someone copies back by hand.

---

## What to take, and what to leave

How this build actually applies the list below — and what it measured when it did — is [[the-vault-projection]].

**Take the primitives.** Files, folders, flat properties, internal links, derived backlinks, assets, saved queries, canvases, history, portable export. Everything anyone has built in this field is a view over that list.

**Take two brackets and a stable identifier.** The link syntax and the permanent address are the only two decisions that are expensive to change later.

**Take the separation of authored from generated.** A map of content is written. An index is derived. A backlink list is derived. Conflating them produces a system where nobody can tell whether a page's connections were a judgment or a side effect.

**Leave the folder methods as taxonomy.** PARA and its relatives sort by actionability. A research corpus is not sorted by actionability; the same page is needed at unpredictable intervals forever.

**Leave the app-shaped features.** Cloning a plugin ecosystem is an unbounded project that ends in a worse copy of the original.

**Leave any format you cannot read without its application.** That is the whole lesson of the entries above that no longer exist.

---

## How to use this register

Each entry above is a thing to watch, not a thing to have read. The field moves in a specific way: a format gets specified, then apps implement it, then methods get written about it, then the methods get commercialised and the useful part gets buried. Watching the format layer is the highest-signal habit — JSON Canvas being published as an open spec did more for interoperability than any amount of writing about note-taking.

When a new entry appears, three questions decide whether it matters here:

1. **Does it define a format, or consume one?** Format definitions change what is possible. Consumers change what is convenient.
2. **Can its output be read with no software but a text editor?** If not, it is a destination, not a substrate.
3. **Does it make an operation mechanical that was previously judgment?** Those are the ones to copy immediately.

Everything else is a preference, and this register does not track preferences.


## Sources

1. Obsidian Help — Internal links (wikilink syntax) — https://obsidian.md/help/Linking%20notes%20and%20files/Internal%20links
2. Andy Matuschak — Evergreen notes — https://notes.andymatuschak.org/Evergreen_notes
3. Tiago Forte — The PARA Method — https://fortelabs.com/blog/para/
4. JSON Canvas — open file format for infinite canvas data — https://jsoncanvas.org/
5. Obsidian Bases syntax — .base files are plain YAML — https://obsidian.md/help/bases/syntax
6. Karpathy — llm-wiki (GitHub gist, April 2026) — https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
7. Karpathy — llm-wiki, the compiled-artifact argument — https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
8. Quartz — static-site generator for Markdown vaults — https://quartz.jzhao.xyz/
9. Obsidian (software) — creators, release dates, storage model — https://en.wikipedia.org/wiki/Obsidian_(software)