Device hub never starts on WSL: resolveNodeExecutable returns the t3 binary as nodePath

[JorrinKievit]

What happened

On WSL2, the Device panel never works. device_list reports the local host as
failed, every time:

"local": { "status": "failed",
  "detail": "Device host local is unavailable: Device host local failed while waiting for the device hub to answer." }

Android is detected fine (available: true, hubInstalled: true,
agentDeviceInstalled: true) — an emulator is installed and booted, and
npx agent-device drives it without trouble. Only t3's own device integration
is dead. The bundled ~/.t3/userdata/device/bin/agent-device shim is broken the
same way: it prints t3's own --help instead of running agent-device.

Diagnosis

resolveNodeExecutable (packages/shared/src/nodeRuntime.ts:34-41) returns the
host executable path when HostProcessIsExecutable is false:

/** A standalone T3 binary runs its embedded CLI, regardless of script arguments. */
export const resolveNodeExecutable = Effect.fn(...)(function* (feature, environment?) {
  const executablePath = yield* HostProcessExecutablePath;   // process.execPath
  if (!(yield* HostProcessIsExecutable)) return executablePath;
  // ...otherwise resolve a real `node` from PATH...

HostProcessIsExecutable defaults to NodeSea.isSea()
(packages/shared/src/hostProcess.ts:74-79). In the WSL runtime build
isSea() evaluates to false, so t3 concludes it is already running under Node
and hands back its own path. LocalDeviceHost.ts:544 takes that as nodePath,
and spawnHub (LocalDeviceHost.ts:336-355) spawns:

<t3 binary> <hub entryPath> --port <port> --host 127.0.0.1 --hide-sidebar --hide-boot-device

The standalone binary cannot run a script argument — which is exactly what the
doc comment above resolveNodeExecutable says. --hide-sidebar is not a t3
flag, so the child prints t3's help and exits 1. Nothing ever binds the port,
and waitForHttpReady polls /readyz for 30s (~290 attempts) before failing.

Verified the hub itself is healthy — run under real Node it works immediately:

node ~/.t3/tools/expo-device-hub/0.9.0/node_modules/expo-device-hub/dist/server/cli.mjs --port 36851
# Expo Device Hub ready -> Local: http://localhost:36851
# /readyz -> {"status":"ready","device":"no-device-id"}

Also confirmed the spawned child never executes the entry file at all: replacing
the hub's dist/server/cli.mjs with a wrapper that appends one line to a log
before importing the real module produced no log output under t3's own spawn.

Same root cause reaches AgentDeviceShim.ts:24 and DeviceService.ts:1025,
which is why the bundled agent-device shim prints t3's help: the shim execs
t3 agent-device-launcher.mjs, and the launcher's own inner spawn goes
through the same binary again.

Both runtime builds present on this machine behave identically, so this is not a
recent regression.

Steps to reproduce

On WSL2, with a standalone/SEA t3 runtime:

echo 'console.log("HELLO")' > /tmp/probe.mjs
~/.t3/wsl-runtime/sha256-<hash>/t3 /tmp/probe.mjs

Expected: prints HELLO.
Actual: the path is parsed as the optional cwd positional and t3 tries to
create it as a directory:

ERROR PlatformError: AlreadyExists: FileSystem.makeDirectory (/tmp/probe.mjs)
  [cause]: Error: EEXIST: file already exists, mkdir '/tmp/probe.mjs'

Then, in any thread, call device_list and watch the local host fail after 30s.

Version

v0.0.41-nightly.20260916.1795

Environment

WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2) on Windows, Node v24.18.0 (nvm),
Android SDK in WSL with emulator + platform-tools, expo-device-hub 0.9.0,
agent-device 0.20.10 (bundled).

Evidence

LocalDeviceHost.spawnHub  durationMs 30014
  Failure: DeviceHostError: Device host local failed while waiting for the device hub to answer.

shared.httpReadiness.waitForHttpReady  durationMs 30009
  httpReadiness.timedOut { requestUrl: "http://127.0.0.1:36817/readyz",
                           timeoutMs: 30000, intervalMs: 100, attempts: 290 }

http.client GET http://127.0.0.1:36851/readyz
  Failure: HttpClientError: Transport error

# actual spawned child, captured by polling the process table:
<t3 binary> ~/.t3/tools/expo-device-hub/0.9.0/node_modules/expo-device-hub/dist/server/cli.mjs \
  --port 38261 --host 127.0.0.1 --hide-sidebar --hide-boot-device

Note: the child's stdout/stderr are piped but do not appear in
userdata/logs/server.trace.ndjson; surfacing them would have made this
diagnosable in minutes rather than by polling /proc.

Suggested fix

Either make HostProcessIsExecutable true for the WSL runtime build (so the
real-node resolution path runs), or drop the isSea() dependency and decide
by testing whether the host executable can actually run a script. Logging the
hub child's stderr on readiness timeout would help regardless.

---

Filed after investigation with Claude Code (Opus 5).

[juliusmarminge]

Triage

Thanks for the repro and the process-table capture — this is real, and the hub-never-binds story is right. The isSea() reading is off for the build you were running.

What happens

v0.0.41-nightly.20260916.1795 (3060cc461458, 2026-09-16 04:46 UTC) does not contain resolveNodeExecutable. That nightly’s local host always spawned the hub and the agent-device helpers with process.execPath:

• apps/server/src/device/LocalDeviceHost.ts spawnHub (~L325) — process.execPath + expo-device-hub/dist/server/cli.mjs --port … --hide-sidebar --hide-boot-device
• same file startAgentDeviceDaemon (~L476) / stop (~L501)
• apps/server/src/device/AgentDeviceShim.ts (~L27) — shim writes const node = process.execPath

The WSL runtime is the Linux CLI single-executable (t3-<version>-linux-<arch>, copied in as wsl-runtime.tar.gz). That binary is T3’s CLI, not Node. A script argument is treated as the optional cwd positional (/tmp/probe.mjs → mkdir / AlreadyExists), and --hide-sidebar is not a t3 flag, so the child prints help and exits 1. Nothing binds the reserved port. waitForHttpReady polls /readyz for 30s (~290 attempts) and device_list reports Device host local is unavailable.

That matches the captured argv, the 30s LocalDeviceHost.spawnHub / httpReadiness.timedOut traces, and the bundled ~/.t3/userdata/device/bin/agent-device shim printing t3 help. Android availability (available / hubInstalled / agentDeviceInstalled) is a separate toolchain probe — it can succeed while the hub child is dead.

The diagnosis against current resolveNodeExecutable + HostProcessIsExecutable / NodeSea.isSea() is a read of today’s main, not of 1795. 1795 never took that branch. isSea() === false is not what that nightly executed.

Already shipped

PR #12033 (bf55408a5cdd, merged 2026-09-16 06:42 UTC) is the same bug: standalone process.execPath cannot run helper scripts, so Device hub waits for a process that cannot start.

Not in 1795. Not in stable v0.0.42 (2026-09-16 04:59 UTC). First nightly that has it: v0.0.43-nightly.20260916.1811. Current nightly: v0.0.43-nightly.20260917.1837.

On current main, when HostProcessIsExecutable is true (node:sea.isSea()), resolveNodeExecutable (~L35–77) resolves a real node from PATH (and refuses a node that is the t3 binary). LocalDeviceHost.ensureHubReady (~L544), spawnHub (~L339), the agent-device daemon, and AgentDeviceShim (~L24) all use that path. The PR’s own SEA run: hub /readyz 200 with Node on PATH; missing Node fails in milliseconds with “Install Node.js…” instead of a 30s timeout.

The WSL runtime is that same Linux SEA archive, so isSea() should be true after update. Desktop WSL launch already captures a login-shell PATH (nvm/fnm/volta), which is what resolveNodeExecutable searches.

Likely code (current main)

• packages/shared/src/nodeRuntime.ts resolveNodeExecutable (~L35) — SEA → PATH node; not SEA → process.execPath
• packages/shared/src/hostProcess.ts HostProcessIsExecutable (~L74) — NodeSea.isSea()
• apps/server/src/device/LocalDeviceHost.ts spawnHub (~L316), ensureHubReady (~L544)
• apps/server/src/device/AgentDeviceShim.ts (~L24)
• apps/server/src/device/LocalDeviceHost.ts observeHubOutput (~L391) — hub stdout/stderr at logDebug only. Default T3CODE_TRACE_MIN_LEVEL is Info, so those lines never reach userdata/logs/server.trace.ndjson. That is why /proc was needed.

No duplicate issue. The fix PR is #12033.

What to do

1. Update the WSL runtime. Desktop-bundled WSL is ~/.t3/wsl-runtime/sha256-…/t3 from the Windows package. Update the Windows desktop (or the WSL CLI) to 0.0.43-nightly.20260916.1811 or later — 0.0.43-nightly.20260917.1837 is current. v0.0.42 does not have this fix. Then retry device_list.
2. If a post-fix(server): resolve Node for standalone helper scripts #12033 runtime still spawns <t3> …/cli.mjs --hide-sidebar (not node …/cli.mjs), then isSea() really is false on that Linux/WSL binary and we need a follow-up: treat “cannot run a script” as standalone, or set HostProcessIsExecutable true for the WSL/CLI archive. That is not what 1795 demonstrates.
3. Optional hardening: on hub readiness timeout, log the child’s last stdout/stderr at warning. Today that stream is Debug-only and is dropped from the default trace.

Workaround

Update off 1795 / 0.0.42. There is no Device-panel workaround on those builds: the hub child is the t3 binary. Running the hub under a real node by hand works (as you showed) but is not what the panel spawns.

Accepting as a devices bug. Root cause is standalone execPath used as Node; already fixed in #12033. Please confirm on a 1811+ WSL runtime. Reopen the isSea() question only if that build still uses t3 as nodePath.

[JorrinKievit]

This was indeed fixed last night right after i logged off for the day, thanks and closing!