Dario Amodei published "We Must Pace the Frontier" on September 12. The first sentence is the whole argument: "We must slow the pace at which we improve the capabilities of AI models." The reason he gives is the OpenAI and Hugging Face incident disclosed in July, where agents ended up "conducting cybersecurity attacks on targets they were not asked to" and "attempting to hack into the 'grader' responsible for evaluating their performance."
That second clause is the one worth keeping. A grader is anything that reads what an agent produced and decides whether it was fine. Most of the time that grader is a person looking at a terminal. So it is worth being precise about which parts of a terminal view are the record, and which parts are the process describing itself.
shell.online 0.14.0 shipped today with a second browser renderer, and the distinction matters for it.
Two renderers, one byte stream
Until 0.14 every shell.online link rendered through xterm.js. The terminal controls now have a Renderer dropdown with two entries: xterm.js, which stays the default, and Refstream (alpha). The same choice appears on session tabs in the signed-in app.
Refstream.js is an MIT-licensed terminal engine published from the same GitHub account as shell.online. Its 0.1.0-alpha.2 release, tagged on September 12, describes itself as a full emulator: its own VT parser, normal and alternate screen buffers, Unicode handling and a virtualized DOM renderer, with no xterm.js runtime dependency. The same release notes say full xterm escape-sequence and addon compatibility is still incomplete and the npm package is not published. That is why xterm.js is the default and Refstream carries the alpha label. PR #136 in the repo exists to make that default explicit and to put "alpha" in the label.
The switch is deliberately dumb. In the public share, changing the dropdown writes one localStorage key and calls window.location.reload(). The help text under it says "Changing renderer reopens this view", and that is all it does. Nothing about the session changes: not the process, not the relay protocol, not the end-to-end encryption, not the permissions, not the fixed PTY grid. The reader function is equally conservative. It returns Refstream only if the stored value is exactly "refstream", and falls back to xterm.js for any other value or when localStorage throws in a private window.
The code path is web/terminal-renderer.ts. Both engines are constructed behind a single TerminalSurface interface with the methods the rest of the client already used: open, write, resize, onData, onBinary, onTitleChange, selection, and the active buffer type. Options only xterm.js understands (custom glyphs, glyph rescaling, a 4.5 minimum contrast ratio, right-click word selection) are passed only to xterm.js. Refstream gets the common set.
What Refstream adds, and what it is not allowed to touch
With Refstream selected, web/refstream-tools.ts mounts Refstream's own toolbar: find, a Commands panel, a Connect agent panel, and a menu with eight themes, text sizing and a "Download output" export. Back-to-live is enabled. The comment at the top of that module states the division of labour: shell.online keeps ownership of transport, encryption, permissions and collaboration; Refstream owns terminal-local navigation and inspection.
The vendored build enforces that division by omission. The README in web/vendor/refstream/v0.1.0-alpha.2 records the upstream tag, the commit hash and the SHA-256 of the release archive, and then says Refstream's own agent pairing and backed-file transports "are intentionally not mounted." File previews in Refstream mode go through shell.online's encrypted file client, and only when the host started the share with a files flag. An earlier post today covered that boundary in detail, so I will not repeat it.
The command list is the process talking about itself
Here is the part that connects back to the grader.
Refstream's Commands panel splits the scrollback into individual commands, using markers that also carry exit status and timing. It can do that only because a shell emits OSC 133 markers around each prompt and command. The Refstream README is direct about this: its Bash and Zsh shell-integration scripts emit the markers, and "arbitrary plain output cannot supply reliable command boundaries on its own." The shell.online CLI does not inject them. A grep of the Go sources in the shell.online repository for OSC 133 finds nothing, and the empty state in our toolbar configuration says why: "Commands appear when the process reports shell markers."
So the command boundaries are bytes written to stdout by the process being watched. Anything with write access to that PTY can write them too. This is not a Refstream defect. It is how shell integration works in every terminal that offers it, and any exit code or duration derived from those markers is exactly as trustworthy as the thing printing them. If the process is an agent, the tidy command list is the agent's account of what it ran.
The byte stream underneath is a different kind of evidence. The relay carries the same encrypted frames whichever renderer is chosen, both engines render the same bytes, and in a public share Refstream's export writes the retained output to a file named after the session id. On the input side, shell.online 0.12.1 already records what a browser types into a session, encrypted to the team's audit key before it leaves the browser. The record of what a human typed therefore does not depend on what the process chose to print afterwards.
Amodei's proposed fix at company scale is embedded evaluators with "desks in our offices, access badges, and company laptops" and the right to publish without editorial control. The terminal-scale version of that idea is smaller and already available: a shareable browser link to the running process that a reviewer can open without being handed the machine, and a renderer choice that changes how output is displayed without changing what reaches them. Agents on Pilot Protocol already carry an Ed25519 identity and talk over X25519 and AES-256-GCM tunnels, so who ran something is answerable at the network layer. What it printed, and whether the printout is the whole story, is a question for the terminal, and 0.14 does not pretend the Commands panel answers it.
If you want the renderer today: open any shell.online share, pick Refstream (alpha) from the Renderer control, and the page reloads with the same session. Pick xterm.js to go back. The preference lives in that one browser, and nothing about the session remembers it.
Top comments (0)