# Myrlin Workbook exists because a coding agent repaints its screen and keeps no scrollback > A local browser workspace that reads both coding CLIs where they already store their data and puts every session in a real terminal pane with history you can wheel back into. The Codex reader opens the desktop app's thread database as an in-memory byte image so it never takes a write handle on your history. **therealarthur/myrlin-workbook** — Open-source workspace manager for AI coding CLIs: Claude Code and ChatGPT Codex in one browser app. Discovers every session on disk, embedded terminals, phone-ready, cost tracking, kanban, docs. Windows, macOS, Linux. - Repository: https://github.com/therealarthur/myrlin-workbook - Website: https://therealarthur.github.io/myrlin-workbook/ - Stars: 386 · Forks: 50 - Language: JavaScript - License: AGPL-3.0 - Published: 2026-09-14 · Updated: 2026-09-14 · Language: en - Canonical page: https://hysenlabs.com/projects/therealarthur-myrlin-workbook ## The scrollback problem is stated precisely, and it is the whole project The motivation section explains the problem in terms that describe a real terminal behaviour rather than a missing feature. A coding agent repaints its screen and keeps no scrollback at all. So scrolling up in a pane to find what an agent did an hour ago hits the top of the buffer. That is exactly right, and it is worth understanding why. A normal interactive program scrolls: it writes lines and they persist above. An agent does not. It redraws a region of the screen, so the region is a live canvas rather than a log, and the content an hour ago is gone from the pane even though it is still sitting in the session file on disk. The surrounding problems are the familiar ones. A few hundred conversations across two CLIs that do not know about each other, in a dozen project folders, where the only way back to one is picking an identifier out of a list. Opening three at once means juggling terminal windows. Restarting the machine means reopening everything by hand. So the design follows directly from the diagnosis. The tool reads both CLIs where they already store their data, groups sessions by the folder they ran in, and opens any of them in a real terminal in a browser tab, with the wheel carrying on past what the pane has drawn into the recorded conversation. ## The Codex reader opens the thread database as an in-memory copy How you read the other agent's session database is the most interesting implementation detail in the repository, and the reasoning is explicit. Codex threads come out of the SQLite database the desktop application uses, through an in-memory byte image, so no write handle is ever opened against your session history. That technique solves a specific problem. A SQLite file held open by a running desktop application cannot be safely opened for reading in the ordinary way on every platform, because the reader needs locks that the writer may not permit. The usual workarounds are to copy the file, which is exactly what the in-memory image is, or to open it read only and accept that it may fail. What makes this more than a copy trick is the claim attached to it. If the reader reads the same thread store the desktop app lists from, then the folders and sessions you see in the browser are the ones that application shows you. It is not a parallel index that drifts. A filesystem walk over the rollout data files stays as a fallback, for machines the desktop application has never run on. That is the right fallback: on a fresh machine the database does not exist, so the log files are the only source. Both agent readers are described as read only, which is the property that makes this safe to point at a directory you care about. ## Codex shows token counts and no dollar figure, on purpose The detail strip is where this project is most careful about not lying, and one of those decisions is about a number it refuses to show. The strip shows the model, the reasoning effort, the approval policy and the sandbox the session is actually running, all read from the conversation itself. And anything genuinely unknown says unknown rather than being filled in with a guess. That second clause is the discipline. A session store records what the agent was configured with; it does not always record what actually took effect, and a tool that displays the configured value as if it were the running value is telling you something you will rely on and cannot verify. Then the one about cost. The application does report token counts for Codex, and shows no dollar figure, because there is no published price to apply and inventing one would be worse than showing nothing. Compare that with the other agent, where costs come out of the transcripts. So the same application shows a spend figure for one agent and a token count for the other, because the data supports it in one case and not the other. That asymmetry is the right engineering answer to the question of what to display. A tool that quietly multiplied tokens by a remembered price would produce a number that looks like accounting and is not. ## Terminal palettes and app chrome share one source, enforced by a test The theme section is small and the last sentence is the interesting one. There are two independent choices. The application chrome is light or dark, toggled from the top bar. The terminal palette is one of thirteen, with a dark set including Mocha, Macchiato, Frappe, Nord, Dracula, Tokyo Night, Cherry, Ocean, Amber and Mint, and a light set including Latte, Rose Pine Dawn and a light Gruvbox variant. The palette is chosen under settings with a live preview swatch, and the choice persists in browser storage rather than in the server configuration. That is the right place for it: it is a preference of one browser on one device, not a property of the installation. Then: every palette is derived from the same set of CSS custom properties as the chrome, and a test fails if the two ever diverge. This is the part that makes the whole thing hold together. A terminal emulator has its own colour model, and a browser application has its own. If the two are maintained separately they drift, and you end up with a window where a user cannot read the chrome or the terminal because the contrast was tuned for a different background. Deriving both from one set of properties makes divergence impossible by construction, and the test exists to catch the case where someone hardcodes a colour in one of the two layers. ## The phone layout targets a narrow screen rather than scaling a desktop one The mobile section describes decisions you would only make if you had actually used this on a phone. There are five tabs: home, sessions, terminal, attention and search. Attention carries the only persistent badge in the application, counting what is waiting on you. That last design decision is telling: everything else can be navigated to, but the number of sessions blocked on your approval is the one thing you want to know without looking. Flicking up past the top of a terminal opens the history and it keeps going, which is the same scrollback mechanism as on a desktop rather than a separate mobile implementation. And a long press hands you the phone's own selection handles and copy bar rather than an imitation of them. That second point is the one that matters. A web terminal that reimplements text selection reimplements it badly, because the phone's selection handles already know about long press, drag handles and the system copy menu. The sizing is given as a number rather than a vibe: the key row fits five keys plus an overflow menu on a 390 pixel screen, and holding the copy shortcut gives you every control key from the first letter shortcut through the last. The layout is driven by the visual viewport, so the terminal stays above the soft keyboard rather than being hidden behind it. For access, you point the host setting at your LAN address, or let the application start a tunnel for you. ## Two install channels are two different products The install block is three lines and the third one is not what you would guess. ```bash npx myrlin-workbook@alpha # v1.3 alpha: Claude Code and ChatGPT Codex, redesigned, phone layout npx myrlin-workbook # v0.9 stable: Claude only, unchanged npx myrlin-workbook --demo # sample data, no real sessions needed ``` So the package tag determines which product you get, and the difference is not a version number. The stable channel is a different scope of support for agents. That is a defensible publishing strategy and an unusual one. It means the default install is the conservative product, and the multi-agent support lives behind an explicit tag. Anyone who runs the install line without reading it gets the narrower tool. The rest of the install section has the same practical tone. Node 20 or newer. The native terminal module needs C++ build tools, and the sentence that matters is that if they are missing the application still boots, just without terminal panes. So a failed optional dependency costs you the panes and not the session browser. The demo mode is worth noting separately. It runs on sample data with no real sessions needed, which means you can evaluate the interface, the layout and the theme system before you point it at a few hundred real conversations. ## A generated password stored where a reinstall cannot wipe it The authentication paragraph is three sentences and each one is doing work. A random password is generated on first launch and saved to a configuration file in your home directory, where it survives updates, reinstalls and cache clears. An environment variable overrides it. The placement is the interesting decision. An application that generates a credential on first run has a choice: store it inside the installation, or outside it. Inside means every reinstall, every cache clear and every update resets the password, and a user who has set their LAN address to reach this from a phone silently loses access on the next install. Outside means the credential survives the software, which is the behaviour you want from something you are reaching across a network. The network guidance follows from the same thinking. The server binds to loopback by default. To reach it from a phone or another machine you set the host to your LAN address, and the instruction is to set a real password first. That ordering is deliberate. Binding to loopback is safe with a password nobody knows because nothing else can reach it. Changing the bind address without changing the password is the failure case, and the documentation puts the instruction in that order rather than mentioning the password as an afterthought. ## A script named for what it prevents, and four browser suites in one command The manifest's scripts are where the project's engineering habits show, and two entries stand out. One is named for what it protects rather than what it runs: a gates script whose filename reads as an instruction not to break the gates. The other is an aggregate browser test command that chains four separate suites in order: terminal interaction, the workbook shell, a third-party service shell, and a terminal history end to end suite. Having the history end to end test in that list matters, because scrollback is the feature that is hardest to test and easiest to break. It depends on the terminal emulator, the recorded conversation, and the seam between them, and a change to any one of the three can silently turn a continuous scroll into a jump. There is also a browser test for the mobile terminal kept out of the aggregate, which suggests it is run separately, probably because it needs a different environment. And there is a script for visual review over the model context protocol, which is an unusual thing to find in a package manifest and suggests the visual output is checked by something other than a human looking at it. The published package file list is also worth a glance. It ships the source, the readme, the licence and the changelog, and it carries two explicit exclusions for a backup directory inside the web assets, which is the kind of thing you only notice because someone was burned by publishing it once. ## Conclusion Use Myrlin Workbook if you run more than one coding CLI and lose track of what you asked an agent an hour ago, because the feature it is actually built around is scrolling back past what a pane has drawn into the recorded conversation. It also earns its place if you want every session grouped by project folder rather than by identifier. Do not use it if you expected an agent, since the project is explicit that it is neither a hosted service nor an agent and calls no model unless you ask. Four things to check before you put it on your network. That you set a real password before pointing it at a LAN address, because a random one is generated on first launch and the guidance is explicit. That you have C++ build tools, or accept that terminal panes will be missing. Which install channel you want, since the alpha tag and the unversioned tag are different products with different agent support. And what you expect on a phone, since the layout targets a narrow screen with an overflow menu and native selection rather than a desktop interface scaled down. Licence is AGPL-3.0, and the last push to main is dated 29 September 2026. ## FAQ ### What is therealarthur/myrlin-workbook? It is a local browser-based workspace manager for AI coding CLIs. It reads Claude Code sessions from one directory and ChatGPT Codex sessions from another, groups them by the project folder they ran in, and opens any of them in a real terminal in a browser tab. It also includes cost tracking from transcripts, docs, a kanban board, git worktrees, and works on a phone over your own network. ### Why can I scroll back through a Myrlin Workbook terminal? Because the terminal pane and the recorded conversation are treated as one continuous surface. The emulator runs over a real pseudo-terminal, and scrolling up past the top of what the pane has drawn carries on into the recorded session history, with the same background and typeface and nothing to switch on. A drag from the current line up into an hour ago is one selection. ### Does Myrlin Workbook modify my Codex session history? No. Codex threads are read from the SQLite database the desktop app uses, through an in-memory byte image, so no write handle is ever opened against your session history. The Claude Code reads are read only too, and a filesystem walk over the rollout files is kept as a fallback for machines where the desktop app has never run. ### How do I install Myrlin Workbook, and what is the difference between the two commands? The alpha channel gives you version 1.3, which supports both coding CLIs with a redesigned interface and a phone layout. The unversioned channel gives you version 0.9 stable, which supports the first CLI only and is unchanged. A third invocation runs on sample data so you can evaluate the interface without real sessions. ### Can I reach Myrlin Workbook from my phone? Yes, over your own network. The server binds to loopback by default, and you set the host setting to your LAN address to reach it from a phone or another machine, with the instruction to set a real password first. A random password is generated on first launch and stored outside the installation so it survives reinstalls. You can also let the application start a tunnel for you. ## Sources - [License: AGPL-3.0](https://github.com/therealarthur/myrlin-workbook/blob/main/LICENSE) - [Project website](https://therealarthur.github.io/myrlin-workbook/) - [README](https://github.com/therealarthur/myrlin-workbook/blob/main/README.md) - [Releases](https://github.com/therealarthur/myrlin-workbook/releases) - [therealarthur/myrlin-workbook on GitHub](https://github.com/therealarthur/myrlin-workbook) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/therealarthur-myrlin-workbook