Why can’t the people who produced the technology, which has already shown that a different world is possible, just do the things that would prevent extinction?

Bram is a desktop app that embeds Claude Code and/or Codex. It makes agentic software development legible, orderly, accountable, and collaborative.

I feel like we've collectively forgotten how much safer food and cars and basically everything else gets, and how fast that happens, as soon as there's real liability involved. Because strict liability is how you align the incentives of corporate behaviour with the general public good, and aligned incentives are magic. https://www.nytimes.com/2026/09/25/technology/openais-ai-us-government-websites.html

bram-xmlui-stress-test.md. GitHub Gist: instantly share code, notes, and snippets.

Attached: 1 image NSF grants will fall to *half* of what they were before the Trump Admin this year, the lowest number since the early 1980s. Why? (1) The White House is withholding $1 Billion for private projects, and (2) The NSF is using every accounting trick to make it look like they are spending without making new grants. New reporting from Dan Garisto at Nature, using Grant Witness data. https://www.nature.com/articles/d41586-026-02574-6 #NSF #Science #USpol

The vanishing of Mitch McConnell.

The Bram binary now embeds SQLite with its FTS5 fulltext indexer and search engine. When you run Bram in a local GitHub (or GitLab) repo, here is what it indexes: – the JSONL session files written by Claude Code and/or Codex – the worklist items written by Bram – git commits – issues posted to GitHub or GitLab The screenshot, from Bram’s own repo, shows that _StickyBox_ is found in all of the indexed buckets: agent sessions, commits, issues, and worklist history. (The date slider is pushed back because I’m looking for earlier occurrences.) When I added the search feature a few days ago I was thinking mainly of my own need to find things scattered across these buckets. But of course agents can use this unified search too! Here’s Claude Code proposing an XMLUI solution. (Spoiler alert: it won’t work.) It proposed to use StickyBox to top-anchor the Find box you see in that screenshot, which reminded me that I’d been avoiding StickyBox for reasons I couldn’t fully articulate. So I asked Claude Code to investigate. Its cross-bucket searches found “the receipts” — the doomed StickyBox attempt in the earlier session unearthed by search — and investigation led to a different solution: StickySection (with top=”$height-AppHeader”). ## Bram and XMLUI These screenshots capture real use of Claude Code via the UI that Bram wraps around it. That UI is made with XMLUI: Bram is a Tauri app that combines a terminal and an XMLUI app that fronts Claude Code and/or Codex. As a co-maintainer of XMLUI and author of its CLI and MCP server, one of my goals has been to make XMLUI reliably learnable by agents. The MCP server provides agents with tools for listing components and searching documentation, and tells agents to prefer _xmlui_list_howto_ and _xmlui_search_howto_. These tools explore the HowTo section of the docs where we’ve assembled nearly 200 verified patterns. Crucially these are backed by playgrounds that run the examples live and prove they work. This is the gold standard. When agents propose an XMLUI solution they are instructed to use, and cite, known working patterns. We always used to say that documentation was integral to a software product, but that was never really true because the docs were never amenable to the same kind of engineering discipline that governed the code. Now documentation has become a testable discipline. When an agent fails to find a working pattern, that’s an XMLUI bug. If I add a HowTo doc that enables the agent to find the working pattern the next time, that’s a fix. ## Make it easy to do the right thing I use Bram to develop a half-dozen different apps. When I’m working on one or another of them and discover a missing XMLUI HowTo, I know I should pause, research the problem, and create that HowTo. But in the thick of the action that is unlikely to happen, so these unanswered MCP queries accumulate. Now it’s much easier to mine project history, find unanswered questions, answer them, and continue to improve the XMLUI MCP server. Here’s the HowTo that emerged from the StickyBox/StickySection investigation. There’s another level to this game. Because the MCP server logs tool calls, an agent’s failure to find verified HowTo docs can be timestamp-matched with conversation and worklist activity. Could agents mine the indexed corpus looking for cases where we’ve struggled to find a solution, and infer missing HowTo docs? Absence of evidence is, of course, not evidence of absence, and I’ll save the still-experimental method for another post. Meanwhile the unified search makes it easy to do the right thing when an unanswered question pops up. ### Share this: * Email a link to a friend (Opens in new window) Email * Share on X (Opens in new window) X * Share on Facebook (Opens in new window) Facebook * Share on Reddit (Opens in new window) Reddit * ### Like this: Like Loading…

Agents are hardwired to be prolific writers and readers of code. As my work on Bram progressed I found that their code-first instinct wasn’t serving me well. So I began pushing them to be, also, prolific writers and readers of logs. Bram is a Tauri app, so it’s written in Rust. But it’s also a JavaScript app that hosts a terminal where Claude Code and Codex run, and it’s an XMLUI app that reimagines how to display and interact with those terminal-based agents, and it’s a workflow governed by a set of Markdown files and Python hooks. The app’s behavior arises from the dynamic interplay of these layers, languages, and components. Was the right message sent to the agent at the right time? Did the rule-defined workflow transition occur? Did the agent’s response render correctly? These are observations about runtime behavior. When something goes wrong, the drill is now: – Do we have the instrumentation to know what happened? – If no, add it. – If yes, use it. This applies as much to developing new features as it does to debugging existing ones. For example, Bram tracks the TUI (text user interface) menus that Claude Code and Codex present, and renders them as GUI menus. It was arguably foolish to even try this kind of screenscraping. Web pages (when not delivered as minified JavaScript) have structure that, while prone to change, is easy to target. Tap into a TUI and you’re looking at a stream of content bytes intermixed with control characters. It’s the source of truth, but a hard one to reason about. So we began gathering evidence. ## The ladder of evidence JSONL session files are the final record. But it can take a few seconds for activity to show up there, and they mainly preserve conversation not interaction. So Bram recruits three other layers: PTY, grid, and hook. ### PTY input These are bytes read from the terminal process, i.e. what the TUI sent. [2026-07-08T13:46:16.407Z] [pty-in] gap_ms=0 bytes=202 preview=”\x1b[?2026h\x1b[18;2H…” Fields: – gap_ms: milliseconds since the previous PTY input chunk. – bytes: raw byte count for this chunk. – runs: optional, count of repeated/compactable control runs. – preview: escaped prefix of raw bytes. ANSI/control characters are preserved as escapes like \x1b, \r, \x07. ### The xterm.js grid The PTY stream isn’t just text, it’s an instruction set for painting a terminal: move the cursor, clear regions, set colors, write characters, update the title, enter or leave bracketed paste mode. Bram uses xterm.js to render those bytes to a terminal grid, then reads the resulting screen state. – [grid-menu] op=report provider=claude count=3 parsed_offset=446235 [1.Yes | 2.Yes, and don’t ask again for: awk -F’]’ ‘$1 >= “[2026-07-07…”‘ | 3.No] – [grid-menu] op=build-claude-nosig tool=Bash grid_count=3 cmd=”grep -E \”hook-menu|retire-suppressor\” bram-trace.log | tail…” grid=[1.Yes | 2.Yes, and don’t ask again for: … | 3.No] The grid layer answers questions that raw PTY bytes cannot answer directly: – What rows are visible right now? – Which text is inside the permission box? – Which option labels are present? This is the layer where TUI screenscraping becomes tractable. It’s not regexes, it’s programmatic inspection of a reconstructed terminal screen. ### PTY Output These are bytes Bram writes into the terminal. [2026-07-08T13:45:24.145Z] [pty-out] bytes=18 preview=”claude –continue\r” is_structured=false caller_hint=agent-autostart Fields: – bytes: number of bytes sent. – preview: escaped text sent to the PTY. – is_structured: whether it came from a structured Bram intent path (propose → apply → commit). – caller_hint: why/where the write originated. ### Hooks Claude Code and Codex both fire lifecycle hooks when using menus to ask permission. Bram’s hook scripts relay those as structured JSON, timestamped into the same trace: – [hook-menu] op=permission provider=claude tool=Edit options=3 – [hook-menu] op=payload tool=Edit body=”{\”tool_input\”:{\”file_path\”:\”src-tauri/src/lib.rs\”,\”old_string\”:…,\”new_string\”:…},\”permission_suggestions\”:[…]}” – [worklist-guard] tool=Edit target=docs/esc-resend-redesign.md decision=deny reason=no-coverage-no-opt-out The hook-menu trace reports a tool name, its full input, and the permission options the TUI is about to draw. ### All the layers PTY logs preserve messy reality: control bytes, cursor movement, bracketed paste markers, title updates, spinner frames. The grid layer turns that byte stream into visible terminal state. Hooks bypass reconstruction entirely, but only for some cases. The JSONL file describes final truth, but again only for some cases. Altogether the traces combine raw, reconstructed, and declared evidence. Interpretation taps into one or several of the layers as it needs to. ### From evidence to construction I can now mostly run Bram in GUI mode without looking at the terminal. Occasionally something gets stuck, so I’m toying with the notion of auto-opening the terminal when it needs attention. Is that reliably knowable? That wasn’t a question the logs could answer so I’ve added new instrumentation. After a day of normal use I’ll know whether the feature is even feasible, and if so, how an agent should build it. ## Deciphering the traces The schemas for these log entries have evolved organically. In the Before Time I’d have worried about that. Would the logs be amenable to structured query? If not, I’d need to write a one-off script to answer each question and that was unsustainable. But for agents, writing one-off scripts is like breathing and Bram’s rendering makes that respiration more visible. In “What is the terminal?” I showed how agents wield the repertoire of command-line tools to make your wishes come true. I see that happening constantly as they reach for awk, grep, sed, and perl to interpret Bram’s logs. Why awk or grep in one case, sed or perl in another? LLMs are nondeterministic but if there is logic that governs these choices I’d love to know what it is. ## Baked-in log-first development As this method evolved, Claude Code and Codex absorbed it into their stored memories. That was convenient, I could just ask “Do we have the instrumentation to support that?” and they’d do the right thing. But those memories aren’t shared between agents, never mind across the various repository-backed projects where Bram can run. As I was writing this post I found that the log-first imperative was, in fact, only recorded in private agent memories. Now it’s baked into any project where Bram runs your agents. ### Share this: * Email a link to a friend (Opens in new window) Email * Share on X (Opens in new window) X * Share on Facebook (Opens in new window) Facebook * Share on Reddit (Opens in new window) Reddit * ### Like this: Like Loading…