You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
agent-relay node up --backgroundsilently skips Cloud-enrollment pickup. The same command in the foreground picks the enrollment up correctly and registers as the enrolled node; with --background it ignores the persisted enrollment, mints a generic local identity, and registers as a direct/implicit node — with no error, no warning, and an apparently healthy node status.
Reproduced on agent-relay 10.6.1 (i.e. with the #1285/#1287 fix), macOS arm64, against prod (cast.agentrelay.com, workspace rw_7ccfea89), 2026-07-16.
Repro
Same directory, same agent-relay.mjs + factory.node.json, same valid persisted enrollment at ~/.agentworkforce/relay/fleet-enrollments.json (nodeId node_203549044126121984, name sf-mini).
Foreground — correct:
$ agent-relay node up --config agent-relay.mjs --no-spawn --verbose
Using persisted Cloud enrollment for node "sf-mini" (workspace rw_7ccfea89).
[fleet] Capability "spawn:claude" registered node=sf-mini ...
[fleet] Capability "spawn:codex" registered node=sf-mini ...
[fleet] Capability "workflow:run" registered node=sf-mini ...
→ no node_id_mismatch
--background — silently wrong:
$ agent-relay node up --config agent-relay.mjs --no-spawn --background --log-file /tmp/x.log --log-level debug
Broker started. Broker PID: 12339
$ agent-relay node status
Status: RUNNING Node delivery: CONNECTED ← looks fine
$ grep -c 'persisted Cloud enrollment' /tmp/x.log
0 ← enrollment NEVER picked up
$ grep 'registered provider' /tmp/x.log
[fleet] Fleet node "factory-node" registered provider "factory-SF-Mac-Mini.home" with 3 capabilities
^^^^^^^^^^^^ directory-derived name, NOT the enrolled "sf-mini"
$ agent-relay fleet nodes
name=direct-203602618734673920 status=offline live=false caps=[] tags=['implicit','direct']
^^^ generic direct node; enrolled sf-mini absent
Why this matters
--background is the daemon mode — it is what anyone running a persistent fleet node uses (a Mac mini, a VM, a container). It is the mode the hosted-node story in AgentWorkforce/cloud#2655 / #2656 depends on.
It fails silently and looks healthy.node status reports RUNNING / CONNECTED; there is no warning that the enrollment was ignored. The only way to notice is to grep the log for persisted Cloud enrollment or spot that fleet nodes shows a direct-* node instead of your enrolled one. An operator would reasonably believe their node is enrolled when it is not.
--background should behave identically to foreground with respect to enrollment: pick up the persisted enrollment, export RELAY_NODE_ID, and register as the enrolled node. If it genuinely cannot (no enrollment for the target workspace, expired, etc.) it should say so loudly rather than silently registering a direct node.
Suggested checks
The --config variant of node up "runs enrollment pickup before delegating" (packages/cli/src/cli/commands/node.ts). Does the --background path delegate/detach before that pickup runs, or spawn a child that re-enters a code path without it?
fix(node): use enrolled fleet node identity #1287 exports RELAY_NODE_ID during pickup and the broker prefers it (crates/broker/src/runtime/init.rs). If the background path forks before the env is exported, the broker falls back to the auto/direct branch — which matches the observed direct-* node exactly.
A regression test should assert the enrolled node name/id appears in fleet nodes after node up --background, not merely that the broker started. The failure here is precisely that "it started" is true while "it enrolled" is false.
Summary
agent-relay node up --backgroundsilently skips Cloud-enrollment pickup. The same command in the foreground picks the enrollment up correctly and registers as the enrolled node; with--backgroundit ignores the persisted enrollment, mints a generic local identity, and registers as adirect/implicitnode — with no error, no warning, and an apparently healthynode status.Reproduced on agent-relay 10.6.1 (i.e. with the #1285/#1287 fix), macOS arm64, against prod (
cast.agentrelay.com, workspacerw_7ccfea89), 2026-07-16.Repro
Same directory, same
agent-relay.mjs+factory.node.json, same valid persisted enrollment at~/.agentworkforce/relay/fleet-enrollments.json(nodeId node_203549044126121984, namesf-mini).Foreground — correct:
--background— silently wrong:Why this matters
--backgroundis the daemon mode — it is what anyone running a persistent fleet node uses (a Mac mini, a VM, a container). It is the mode the hosted-node story in AgentWorkforce/cloud#2655 / #2656 depends on.node statusreportsRUNNING/CONNECTED; there is no warning that the enrollment was ignored. The only way to notice is to grep the log forpersisted Cloud enrollmentor spot thatfleet nodesshows adirect-*node instead of your enrolled one. An operator would reasonably believe their node is enrolled when it is not.--backgrounduser gets nonode_id_mismatcherror and no enrolled node — a silent no-op rather than a loud failure.Expected
--backgroundshould behave identically to foreground with respect to enrollment: pick up the persisted enrollment, exportRELAY_NODE_ID, and register as the enrolled node. If it genuinely cannot (no enrollment for the target workspace, expired, etc.) it should say so loudly rather than silently registering adirectnode.Suggested checks
--configvariant ofnode up"runs enrollment pickup before delegating" (packages/cli/src/cli/commands/node.ts). Does the--backgroundpath delegate/detach before that pickup runs, or spawn a child that re-enters a code path without it?RELAY_NODE_IDduring pickup and the broker prefers it (crates/broker/src/runtime/init.rs). If the background path forks before the env is exported, the broker falls back to the auto/direct branch — which matches the observeddirect-*node exactly.fleet nodesafternode up --background, not merely that the broker started. The failure here is precisely that "it started" is true while "it enrolled" is false.Related