feat(furrow): reach a run's live workspace from anywhere

[AbirAbbas]

A build's workspace is currently only reachable if you happen to be on the same machine as the node. This makes it reachable from anywhere, so the harness that started a run can read the files while the run is still going — including the uncommitted edits, untracked files and dev state a git push would never carry.

It is built so that nobody has to know it is there. Availability is discovered, never configured: a build's result carries a workspace_handle when the mirror is working and simply does not carry one when it is not. There is no flag to set, nothing to probe, and no new failure for a user to understand. Every unavailable path — no binary, no .git, attach or publish failing, the feature switched off — degrades to exactly today's behaviour, and the default (a nil Attacher) is off.

What is here

internal/furrow — resolves a vendored furrow binary the same way internal/pro resolves the engine, attaches a build's clone, republishes at each DAG-level boundary and at completion, and keeps a registry mapping the control-plane run ID to the workspace on disk. That mapping is the thing that was missing: SWE-AF knew its workspaces only by a locally generated build ID, so nothing outside the process could name one. An hourly sweeper bounds what keeping them costs (72h / 20GB by default) because furrow never prunes a remote on its own.

cmd/furrowd + cmd/furrow-dial — the transport. furrowd serves one run's encrypted blob store over TLS by spawning furrow __remote behind a token check; furrow-dial stands in as FURROW_SSH_COMMAND on the caller's side so a stock furrow clone reaches it with no patches to furrow.

Deliberately not sshd: the cloud image runs the control plane and its agent nodes in one container as root, so an ssh key there is whole-box access to every run and every secret on the volume. A furrowd token unlocks a single run's data root, and the payload is ciphertext either way.

get_workspace_handle — returns a run's handle on demand, or {"available": false}.

Three bugs that only a real binary could find

The unit tests inject a fake exec and assert argv, which pins what we mean to run. These are all things a fake happily accepted:

• furrow snap takes -m; there is no --label.
• The recovery key comes back as key_hex, not key.
• .furrowpolicy lines must be exclude <subtree>. Bare names make furrow reject the file, watch then exits non-zero, and the mirror is silently off for every build with one debug line to show for it — the worst failure mode a feature like this can have.

internal/furrow/integration_test.go now drives the real binary end to end (attach → publish → materialize elsewhere → diff) and skips when furrow is not installed, so the CLI contract is checked rather than assumed. The exact policy bytes are pinned in a unit test too, since CI has no furrow binary.

.furrowpolicy also joins .artifacts/ and .worktrees/ in .git/info/exclude — it lands in the repository the agent is working in, and without that it shows up in git status and any acceptance criterion about a clean tree becomes unsatisfiable.

Verified

• gofmt, go build ./..., go vet ./..., go test -race -count=1 ./... — all green, nothing regressed.
• Real furrow binary, end to end: a workspace with an uncommitted edit, an untracked .env and a file written after attach all materialize byte-exact on a separate store, with a usable .git.
• Real transport, end to end: furrow clone ssh://… through furrow-dial → TLS → furrowd → furrow __remote delivers the workspace; a wrong token is rejected.
• Live node against a real control plane: furrow discovered via sibling-binary resolution, 32 reasoners registered including get_workspace_handle, and an unknown run answers available:false rather than erroring.

Not yet exercised: a full LLM-backed build (needs a provider key in the node's environment) and the cloud deployment (its node is still not_configured).

Notes for review

• Freshness is bounded by publish cadence — level boundaries and completion — not a background watcher. watch --no-daemon is deliberate: no orphan daemons inside a container. A periodic publish while a run is in flight is the obvious next increment.
• The namespace on the wire is furrow's blinded name, so furrowd cannot compare it to the registry's; the token is what scopes a connection, and the namespace is charset-validated and passed through. Comparing them rejected every real clone.
• Attaching is restricted to a workspace whose .git is a real directory. A git worktree's .git is a file pointing outside the tree, so mirroring one would produce a clone with no object database.

Review hardening (second pass)

A follow-up review pass added one commit:

• Honest handles: a public ssh:// handle was minted from FURROW_PUBLIC_ADDR alone, even when furrowd never resolved, failed to bind, or exhausted its restart budget — a valid-looking address nothing listens on. The supervisor now exposes a cached process+TCP health signal and the manager falls back to the run's dir: handle (one warning logged) when it is down.
• Durable stores: store/remotes roots defaulted under the workspace tree — ephemeral in cloud containers, so a restart deleted every published store and the TLS identity. When AGENTFIELD_HOME is set (cloud images set /data) the defaults now live under it; explicit env vars still win.
• Sanitized paths: the remote-store dir was joined from the raw run ID while only the namespace was sanitized; ..-shaped IDs could land — and later be swept with RemoveAll — outside the root. The dir now uses the sanitized namespace, with ./.. survivors collapsing to the fallback name.
• Manifest honesty: bin resolution order corrected (/usr/local/bin first, vendored sibling second), and the client-side vars ssh:// consumers actually need (FURROW_DIAL_TOKEN, FURROW_DIAL_INSECURE, FURROWD_TLS_CERT/KEY) are now declared.

go build ./..., go vet ./..., go test -race -count=1 ./... — all green.

[AbirAbbas]

Reviewer note on the transport's threat model, since the client skips certificate verification and that deserves an explicit answer rather than a comment in passing.

What crosses the furrowd connection: the per-run token, then furrow's framed protocol carrying encrypted objects. Object contents, object ids and the workspace name are all encrypted or blinded by furrow before they reach the transport.

What does not: the recovery key. It travels in the workspace_handle inside the reasoner result — over the control plane's own TLS — and is never sent to furrowd. furrowd never has it either; it only shuttles bytes to furrow __remote, which stores ciphertext it cannot read.

So an attacker who fully MITMs the furrowd connection gets a token and a stream of ciphertext. The token lets them pull that one run's objects, which stay unreadable without the recovery key they do not have. They cannot read the workspace, cannot forge a snapshot the real client would accept (objects are BLAKE3-verified against their ids on restore), and cannot reach any other run — the token pins one data root.

That is why the default self-signed certificate is tolerable and why FURROW_DIAL_INSECURE exists. It is not a claim that certificate verification is worthless: an operator who sets FURROWD_TLS_CERT/FURROWD_TLS_KEY to a real certificate gets verification by leaving that variable unset, and that is the better posture on a shared network. The default is chosen so the feature works with no setup, not because the stronger option was unavailable.

The part I would push back on in review is that the token is sent before the client has authenticated the server, so a MITM harvests tokens even though they cannot use them for much. If we want that closed, the options are pinning furrowd's certificate fingerprint in the handle (the handle is already a confidential channel, so it can carry one) or a challenge-response that never puts the token on the wire. Neither is in this PR; the fingerprint would be a small addition if we want it before this is used across untrusted networks.