feat(desktop): open the workspace-sync port when we deploy a control plane

[AbirAbbas]

The desktop half of workspace sync. Pairs with Agent-Field/SWE-AF#130, which teaches SWE-AF to mirror a build's workspace and serve it over a small token-scoped TLS daemon so the coding agent that started a run can read the files while the run is going — uncommitted edits and untracked state included.

That daemon needs one exposed TCP port and an address to advertise. A control plane we provision has neither today, and its agent nodes live inside the same container where nothing but the HTTP domain is reachable.

What changed

The deploy module now declares a railway_tcp_proxy on port 8802 and sets FURROW_PUBLIC_ADDR from its computed domain and port, so a managed deployment arrives with workspace sync already on and nothing for the user to configure — or even know about.

Declarative rather than another GraphQL side-channel like the volume, for three verified reasons: the pinned provider (terraform-community-providers/railway 0.6.2) does have railway_tcp_proxy, so it composes with destroy; Railway's public GraphQL exposes only tcpProxyDelete, with no create mutation available to the desktop's token; and railway_service_domain in 0.6.2 has no port attribute, so a port-targeted HTTP domain isn't an option either.

Sync is an extra and is treated like one. Its outputs are read separately from the ones a deploy actually needs, so a control plane that is up and reachable is a success whether or not a furrow address came back with it. Without that split, a Railway that declined the proxy would have reported the entire deployment as failed — the feature would have become a way to break deploys, which is the opposite of the point. There's a test for exactly that case.

testCloudConnection reports furrow reachability as a status flag with a short bounded probe. It never turns a healthy connection into a failure. Someone who brought their own control plane gets false and one passive line; nothing else changes.

The agentfield-use skill now tells a coding agent what to do with a workspace_handle when it finds one in a result, and says nothing when there isn't one — availability is discovered from the result, never configured or probed. That includes the single carve-out from "never POST to an agent's own port": a handle's endpoint is a furrow transport authorized by a per-run token, not the agent's HTTP surface.

Verified

npm run typecheck and npm test (395 passing, including the new degraded-deploy case). No dependency or lockfile changes.

The schema facts above were confirmed by dumping the provider's real resource schema and introspecting Railway's GraphQL mutation list, not from documentation.

Note

If Railway refuses to create the TCP proxy, tofu apply itself fails and the deploy fails with it — Terraform has no per-resource "continue on error". The result-parsing split above covers a missing output, not a failed apply. If that turns out to bite (a plan without TCP proxies, or the one-proxy-per-service limit already used), the fix is to move the proxy into a second best-effort apply. Worth deciding before this reaches users who have unusual Railway plans.

[AbirAbbas]

Verified this against a real Railway account rather than the provider schema, and the run turned up a defect the schema check could not have caught.

What was exercised. railway_tcp_proxy was applied through the pinned provider onto a live Railway service, then onto a throwaway service running furrowd and furrow from Agent-Field/SWE-AF#130. A client on a laptop ran the agentfield-use skill's ssh:// recipe verbatim — no FURROW_DIAL_ADDR, so the dialer had to recover the address from the ssh-shaped argv — and cloned the container's workspace across the public internet through the proxy. Both a committed file and an uncommitted working-tree file materialised, the latter carrying the container's own RAILWAY_REPLICA_REGION, which is what makes it evidence the bytes came from the cloud rather than from anything local.

The defect. The provider returns the proxy domain as an absolute FQDN on create (trailing dot) and without the dot on refresh. Interpolated raw, a fresh deploy wrote FURROW_PUBLIC_ADDR with the dot and the following plan wanted to rewrite it without — and since a changed service variable restarts the service, a redeploy that should have been a no-op would bounce the control plane. trimsuffix on both reads makes the two forms agree; the follow-up plan is now empty. The regression test was confirmed to fail against the previous module.

Worth saying plainly: this was never a reachability problem. Both address forms reach furrowd — each was used for a successful clone — so the fix is about deploy idempotence only.

Two things learned that are worth keeping. Railway already injects RAILWAY_TCP_PROXY_DOMAIN and RAILWAY_TCP_PROXY_PORT into the service, so FURROW_PUBLIC_ADDR is a convenience rather than the only way a node could discover its address. And creating the proxy restarts the container, which is fine here but means the address is not available to a process that started before it.

Everything created during this has been destroyed: the throwaway project is deleted and the live control-plane service is back to zero proxies, unchanged otherwise.

Still unproven: a full LLM-backed SWE-AF build, and this transport driven by a real node instead of a stand-in for one. Both need an LLM key on the cloud control plane, whose swe-planner-go has been not_configured with zero registrations throughout.

[santoshkumarradha]

Validated this in a clean worktree. The desktop typecheck passed, the desktop Vitest suite passed locally, and the Railway proxy plumbing stays non-blocking for the deploy path while keeping the published furrow address stable across redeploys.