A cloud run from another machine is indistinguishable from yours, and its record ends at the hand-off

[suleimansh]

🤖 automated

Found the night of 2026-08-22 while dogfooding #1640/#1644/#1645 (write-up: #1204 (comment)).

What happened. The Overview's Recent agents showed eight IN CLOUD rows on gemstack and tf-trust-e2e — drain and plan prompts, started within ten minutes — with auto-PM off on this machine and nobody at the keyboard. It took reading tf-data/agents/git@brillout.com/*.json by hand to learn they were four runs of Rom's daemon (host: rom-thinkpad-x280, driver: claude-web), shown twice because tf-trust-e2e is a clone sharing gemstack's tf-data.

Then: had they worked? Each record is the local hand-off only — status: done, handoff: skipped (no-commits), seven seconds from start to end — which reads as "nothing happened" whether the cloud session then planned three tickets (it did) or died. The actual outcome had to be reconstructed from tf-data commits.

Two gaps.

1. Whose run. The record carries host and the archive path carries the account, but the row shows neither. A run from another person's daemon looks exactly like one this daemon started — and the data branch is shared precisely so that other machines' runs appear here.
2. What came of it. For a cloud run the record freezes at the hand-off. The cloud session's result — commits on tf-data, a PR, or nothing — never reaches the row. cloud work adoption brings back what this daemon's cloud runs produce; someone else's never get a second look.

Fix shape. (1) is a label: the row says the host (or "another machine") when host is not this daemon's, and the shared-tf-data duplicate collapses to one row per session id. (2) is the same seam as adoption: a cloud run's record gets a final event when its session's work lands (commits by that session id on tf-data, or a PR from its anchor branch), so done means done.

Repro. Two machines on one tf-data; run anything in the cloud from one; look at the other's Overview.