Daemon never binds to TCP port — missions fail with "factoryd is not reachable"

[z80dev]

Summary

The droid daemon process starts successfully but never creates a TCP LISTEN socket, causing all mission worker spawns to fail with:

Spawn error: factoryd is not reachable (failed to start). Ask the user to restart Droid to recover.

Reproduced on two different machines, two different OS platforms, two different droid versions. The daemon produces zero log output and no error messages.

---

Environment

Machine 1 (macOS)

• OS: macOS 26.3 (Darwin 25.3.0), arm64
• Droid version: 0.73.0
• Shell: zsh
• Auth: BYOK custom models via local proxy (cliproxya on port 8317)

Machine 2 (Linux)

• OS: Linux 6.18.9-arch1-2, x86_64
• Droid version: 0.58.0
• Shell: zsh
• Auth: BYOK custom models

---

Reproduction

# Start daemon
droid daemon --host 127.0.0.1 --port 63000 &
sleep 8

# Verify process is running
ps aux | grep "droid daemon"
# → droid daemon --host 127.0.0.1 --port 63000  ← process exists

# Check for LISTEN socket
lsof -i :63000    # macOS
ss -tlnp | grep 63000  # Linux
# → EMPTY — no listener

# Verify port is bindable (not a firewall/port issue)
node -e "require('net').createServer().listen(63000, '127.0.0.1', () => { console.log('OK'); process.exit(0); })"
# → OK

# Verify firewall is off (macOS)
/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
# → Firewall is disabled. (State = 0)

Also tried:

• --host localhost --port 62917 (original auto-assigned config)
• --host 127.0.0.1 --port 63000
• --debug flag (produces zero additional output)
• Multiple restarts and fresh starts after killall droid

Result is identical every time: process starts, makes outbound HTTPS connections to Factory servers (216.150.x.x), but never binds a local LISTEN socket.

lsof output for the daemon process (macOS)

# Only outbound connections, zero LISTEN sockets:
droid  PID  user  10u  IPv6  ...  TCP [2601:...]:64051->[2600:9000:...]:https (ESTABLISHED)
droid  PID  user  14u  IPv4  ...  TCP 10.0.0.158:64055->216.150.16.129:https (ESTABLISHED)
droid  PID  user  17u  IPv4  ...  TCP 10.0.0.158:64058->216.150.1.129:https (ESTABLISHED)
droid  PID  user  19u  IPv4  ...  TCP 10.0.0.158:64060->216.150.1.129:https (ESTABLISHED)

---

Impact on Missions

When running a mission, droid auto-starts the daemon to spawn worker sessions. Since the daemon never listens, every worker spawn fails. The mission retries repeatedly and eventually pauses.

Progress log from a real mission (progress_log.jsonl):

{"type":"mission_run_started","message":"Mission artifacts authored..."}
{"type":"worker_failed","spawnId":"worker_d68407dc","reason":"Spawn error: factoryd is not reachable (failed to start). Ask the user to restart Droid to recover."}
{"type":"mission_run_started","message":"Retrying mission run after factoryd connectivity failure..."}
{"type":"worker_failed","spawnId":"worker_2b0aad38","reason":"Spawn error: factoryd is not reachable (failed to start). Ask the user to restart Droid to recover."}

This repeated 12+ times across multiple pause/resume/restart cycles. Zero workers were ever successfully spawned. The mission completed 0 of 20 features.

---

Log analysis

~/.factory/logs/droid-log-single.log

Shows [LocalDaemonClient] close() called with hadConnection: false — the client-side confirms it never established a connection:

[LocalDaemonClient] close() called | Context: {"value":{"caller":"droid-cli","hadConnection":false}}

~/.factory/logs/console.log

Contains repeated WASM crashes from yoga-layout during mission worker spawn attempts:

ERROR: An unexpected critical error occurred {
  error: RuntimeError: Out of bounds memory access (evaluating 'MA.apply(null,W9)')
      at <anonymous> (../../node_modules/yoga-layout/dist/binaries/yoga-wasm-base64-esm.js:33:52)
      at OWB (../../node_modules/ink/build/renderer.js:32:49)
      at onRender (../../node_modules/ink/build/ink.js:177:56)
  context: 'Uncaught exception'
}

Daemon stdout/stderr

Zero output, even with --debug flag.

---

Settings

{
  "sessionDefaultSettings": {
    "model": "custom:gpt-5.4",
    "reasoningEffort": "high",
    "autonomyMode": "auto-high"
  },
  "missionModelSettings": {
    "workerModel": "custom:gpt-5.4(high)-0",
    "workerReasoningEffort": "none",
    "validationWorkerModel": "custom:gpt-5.4(high)-0",
    "validationWorkerReasoningEffort": "none"
  },
  "customModels": [
    {
      "model": "gpt-5.4(high)",
      "id": "custom:gpt-5.4(high)-0",
      "baseUrl": "http://127.0.0.1:8317/v1",
      "apiKey": "sk-dummy",
      "provider": "openai"
    }
  ]
}

---

Questions

1. Does the daemon require a Factory-hosted subscription to function, or should it work with BYOK-only configurations?
2. Is the daemon expected to work when started standalone (droid daemon --port X), or must it be launched internally by an interactive session?
3. Are missions supported for BYOK-only users?

---

Possibly related issues

• Mission manager seems to become unavailable to orchestrator after some point #759 — Mission manager becomes unavailable to orchestrator
• Subagents (Task tool) fail 100% on all BYOK models — "No output received" / "Task failed" #691 — Subagents (Task tool) fail 100% on all BYOK models
• Specialist Droid hangs on requests. #211 — Specialist Droid hangs on requests

[z80dev]

Root Cause Found

We did a deep debugging session and identified the exact root cause. The daemon's Bun.serve() is never called — the initialization breaks silently before it gets there.

Evidence chain (all confirmed via Bun inspector at runtime)

1. Ink initializes but has no TTY:

process.stdout.isTTY  → undefined
process.stdout.columns → undefined  
process.stdout.rows   → undefined
stdoutWritePatched    → true  (ink DID initialize)

2. Yoga-layout WASM crashes on undefined terminal dimensions:
From ~/.factory/logs/console.log during daemon startup:

RuntimeError: Out of bounds memory access (evaluating 'MA.apply(null,W9)')
    at yoga-layout/dist/binaries/yoga-wasm-base64-esm.js:33:52
    at ink/build/renderer.js:32:49
    at ink/build/ink.js:177:56

3. The ink component tree that calls server.start() never mounts:

Bun.serve called? → false  (intercepted via inspector)
Active handles:   → 0
Active requests:  → 0
Server instances: → []

4. Bun.serve() itself works perfectly fine:

// Evaluated via Bun inspector inside the daemon process:
Bun.serve({ hostname: '127.0.0.1', port: 63001, fetch: () => new Response('ok') })
// → Successfully bound and served requests

5. The process stays alive as a zombie because outbound HTTPS keepalive connections (to api.factory.ai) prevent the event loop from exiting, even though there are zero active handles.

Why the daemon never gets a TTY

The daemon is spawned by the interactive session with:

spawn(droidPath, args, { detached: false, stdio: "ignore", ... })

stdio: "ignore" maps all streams to /dev/null, so process.stdout.isTTY is undefined. The ink renderer then passes undefined to yoga-layout's WASM as the terminal width, causing the out-of-bounds memory access.

When started standalone (droid daemon --port X), same issue — unless you're running it in the foreground of an interactive terminal (which nobody does for a daemon).

Auth is NOT the problem

All API calls succeed with 200 OK:

• GET https://downloads.factory.ai/factory-cli/LATEST → 200
• GET https://api.factory.ai/api/feature-flags → 200
• GET https://api.factory.ai/api/organization/managed-settings → 200

JWT is valid (expires 2026-03-18, role: owner).

Suggested fix

The daemon command's React/ink component should handle the no-TTY case — either:

1. Skip ink rendering entirely when !process.stdout.isTTY and call server.start() directly
2. Set fallback terminal dimensions (e.g. 80×24) before initializing yoga-layout
3. Use a headless ink render mode

Debugging methodology

For anyone hitting this: set BUN_INSPECT="ws://127.0.0.1:9229/debug" as an env var, start the daemon, then connect with:

bun -e "
const ws = new WebSocket('ws://127.0.0.1:9229/debug');
ws.onopen = () => {
  ws.send(JSON.stringify({id:1, method:'Runtime.evaluate', params:{
    expression: 'YOUR_JS_HERE', returnByValue: true
  }}));
};
ws.onmessage = (e) => console.log(JSON.parse(e.data)?.result?.result?.value);
setTimeout(() => process.exit(), 3000);
"

[z80dev]

Root cause identified: ink render loop blocks Bun.serve() — requires SIGINT to proceed

After extensive debugging, we've identified the precise root cause:

The bug

The droid daemon process starts up and initializes an ink (React terminal UI) render loop that blocks the startup path before Bun.serve() is ever called. The daemon process sits stuck in this render loop indefinitely.

Sending SIGINT (Ctrl-C) to the daemon unblocks startup — the daemon catches SIGINT, cleans up the ink instance, and then proceeds to call Bun.serve() and successfully bind the TCP port. The daemon does not exit; it continues running and serving WebSocket connections normally after receiving SIGINT.

Proof

# Using expect to spawn with a PTY and auto-send Ctrl-C:
expect -c '
  spawn env COLUMNS=120 LINES=40 TERM=xterm-256color droid daemon --host 127.0.0.1 --port 63000
  sleep 3
  send \x03
  sleep 3
  set timeout -1
  expect eof
' &

# After Ctrl-C is sent, the daemon outputs:
# ^C[droid daemon] Daemon is running
#   Version: 0.73.0
#   PID: 59967
#   Logs: /Users/z80/.factory/logs
#   WebSocket endpoint: ws://127.0.0.1:63000
#   Press Ctrl+C to stop

# And it DOES listen:
$ lsof -i :63000 -sTCP:LISTEN
# COMMAND   PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
# droid   59967  z80   68u  IPv4   ...      0t0  TCP localhost:63000 (LISTEN)

Without the SIGINT, the daemon runs forever with zero TCP listeners, even with a valid TTY.

Two failure modes when auto-spawned by missions

1. No TTY (stdio: "ignore" in the spawn code): yoga-layout WASM crashes with "Out of bounds memory access" because process.stdout.isTTY is undefined. The daemon dies before reaching the render loop.

2. With TTY but no SIGINT: The daemon starts, enters the ink render loop, and blocks. Bun.serve() is never called. No TCP listener is created. The mission client times out waiting.

In both cases, the mission worker spawn fails with "factoryd is not reachable."

Suggested fix

The daemon's startup path should call Bun.serve() before (or without) initializing the ink render tree. The server bind should not depend on a terminal UI being set up first. If the ink UI is needed for the "Press Ctrl+C to stop" display, it should be initialized after the server is listening, or the server bind should happen in a code path that doesn't go through the React component lifecycle at all.

[z80dev]

Confirmed fix: missions now working with workaround

Following up on the root cause identified above — we have a working workaround and missions are now running successfully.

Recap of root cause

The droid daemon startup path initializes an ink (React terminal UI) render loop that blocks before Bun.serve() is ever called. The server only binds after receiving SIGINT (Ctrl-C), which triggers ink's cleanup and lets execution proceed to the server bind. The daemon does not exit on SIGINT — it catches it, cleans up ink, then starts serving normally.

When missions auto-spawn the daemon via child_process.spawn("droid", ["daemon", ...], {stdio: "ignore"}), two things go wrong:

1. No TTY (stdio: "ignore"): yoga-layout WASM crashes with RuntimeError: Out of bounds memory access because process.stdout.isTTY is undefined. The daemon dies instantly.
2. Even with a TTY: The ink render loop blocks indefinitely. Nobody sends SIGINT, so Bun.serve() is never reached. The mission client times out after 10 seconds waiting for the daemon to become ready.

Workaround

Replace the droid binary with a shell wrapper that intercepts daemon subcommands, providing a pseudo-TTY via expect and auto-sending Ctrl-C after 3 seconds:

# Back up real binary
cp ~/.local/bin/droid ~/.local/bin/droid-real

# Install wrapper
cat > ~/.local/bin/droid << 'WRAPPER'
#!/bin/bash
REAL_DROID="$HOME/.local/bin/droid-real"

if [ "$1" = "daemon" ]; then
    exec /usr/bin/expect -f - "$@" << 'EXPECT_EOF'
set args [lrange $argv 0 end]
set timeout -1
eval spawn -noecho env COLUMNS=120 LINES=40 TERM=xterm-256color $env(HOME)/.local/bin/droid-real $args
sleep 3
send \x03
expect eof
EXPECT_EOF
else
    exec "$REAL_DROID" "$@"
fi
WRAPPER
chmod +x ~/.local/bin/droid

Why this works:

• expect allocates a real pseudo-TTY for the daemon subprocess → no yoga WASM crash
• send \x03 delivers SIGINT after 3 seconds → breaks the ink render loop → Bun.serve() proceeds
• Works even when the parent uses stdio: "ignore" (expect's PTY is independent)
• Non-daemon invocations pass through to the real binary unchanged

Verified: Missions that previously failed 12+ times with "factoryd is not reachable" are now spawning workers and completing features successfully.

Suggested upstream fix

The daemon's startup path should call Bun.serve() independently of the ink render tree. The server bind should not be gated behind a terminal UI component lifecycle. Alternatively, when running in daemon mode, skip the ink UI entirely — the daemon doesn't need a terminal UI.

[factory-daniel]

Thanks for the comprehensive bug report, and really sorry you had this experience with missions!

We were able to reproduce your error + confirm the workaround, but only when we modified .zshrc to contain commands that require user interactivity.

Can you confirm if there are any interactive or TTY-sensitive components to your zsh shell initialization? This could live in any of your .zshrc, .zprofile, zlogin, etc... files.

This would be super helpful info for us to get a proper fix out, thanks!

[z80dev]

Yes! That did it.

Culprit was a zsh plugin that gets auto-installed by another agent harness (Forge).

I wrapped it in if [[ -t 0 ]] in my zshrc and now droid works as expected.

Thank you for your help!

[factory-daniel]

Of course! We'll work on making daemon startup robust to things like this.

[ajjucoder]

Still happening on v0.83.0 (March 23, 2026) — same root cause: Forge's zsh plugin

Just hit this exact same bug. macOS arm64, Droid v0.83.0, Warp Terminal. 34 consecutive daemon failures across 3 missions, 0/18 features completed. Every single attempt:

[Daemon] Starting droid daemon → [RepoMetadata] Skipping emission → 30s silence → daemon did not become ready in time

The daemon process was alive (3 HTTPS connections to Factory API servers) but never bound its TCP port. lsof confirmed zero LISTEN sockets.

Root cause (confirmed, same as z80dev's)

Forge (ForgeCode) auto-injects this into ~/.zshrc:

eval "$(forge zsh plugin)"
eval "$(forge zsh theme)"

When the daemon spawns without a TTY, these eval calls hang forever waiting for terminal input, blocking the entire startup pipeline before Bun.serve() is reached.

Fix

Either remove Forge entirely (recommended — it's redundant if you have Claude Code or any other agent), or wrap the forge block in a TTY check:

if [[ -t 0 ]]; then
    eval "$(forge zsh plugin)"
    eval "$(forge zsh theme)"
fi

After removing Forge's zsh block, the daemon bound its port in 2 seconds. Missions working perfectly now.

The real fix should be upstream

@factory-daniel you mentioned on March 12 that you'd "work on making daemon startup robust to things like this" — but v0.83.0 (March 20) still has the same vulnerability. The daemon should not run shell init through a user's full .zshrc at all, or at minimum set ZDOTDIR to an empty dir / use --no-rcs when spawning the shell. Any TTY-sensitive plugin in the user's shell config will break missions silently.