Greptile Summary

This PR adds defensive try/catch guards around os.networkInterfaces() calls in three modules (src/gateway/net.ts, src/infra/tailnet.ts, src/pairing/setup-code.ts) to prevent crashes on WSL2 and other environments where the underlying uv_interface_addresses libuv call can fail. It also refactors test-mode detection in config-state.ts and tools-invoke-http.ts from a raw truthy-string check (!!process.env.VITEST) to a strict boolean parse via parseBooleanValue. Each changed path is covered by a new regression test.

Key observations:

• The guard changes are minimal, correct, and preserve all existing behavior when interface enumeration succeeds.
• The "degrade to empty / undefined" fallback is consistent with the handling already in place for interfaces that are present but have no usable addresses.
• The stricter VITEST detection (only "1", "true", "yes", "on" are recognized) is an intentional and tested improvement, but is a behavior change not called out in the PR summary — environments that set VITEST to a non-standard truthy string (e.g. a runner ID or "enabled") will no longer enter test mode through that variable alone.
• The isTestRun helper introduced in tools-invoke-http.ts duplicates the same expression already inlined in config-state.ts; see inline comment for details.

Confidence Score: 4/5

• Safe to merge — the WSL2 guard changes are correct, minimal, and well-tested; the only risk is the undocumented VITEST detection strictness change and minor code duplication.
• All three interface-guard changes follow the same correct pattern and are covered by focused regression tests. TypeScript control-flow analysis correctly handles the let nets / definite-assignment pattern used in each. The test-mode refactor is also well-tested. Score is 4 rather than 5 because: (1) the VITEST strictness change is a real behavior change that isn't surfaced in the PR summary and could silently affect non-standard CI setups, and (2) the isTestRun logic is duplicated between two files without a shared utility, creating a future maintenance risk.
• No files require special attention; src/gateway/tools-invoke-http.ts has the minor duplication noted in the inline comment.

This is a comment left during a code review.
Path: src/gateway/tools-invoke-http.ts
Line: 42-43

Comment:
**Duplicated test-mode detection logic**

The `isTestRun` helper is defined here as a local, unexported function, but an identical expression (`env.NODE_ENV === "test" || parseBooleanValue(env.VITEST) === true`) is independently inlined in `src/plugins/config-state.ts` (lines 142 and 181). If the definition diverges in the future (e.g., a third env variable is added as a test signal), the two copies would need to be updated in sync.

Consider extracting the shared detection to a utility — e.g. `src/utils/is-test-env.ts` — and importing it in both `config-state.ts` and `tools-invoke-http.ts`. That would also make the `env` parameter on `isTestRun` testable without going through the module's internal call sites.

This pattern also appears inline at `src/plugins/config-state.ts:142` and `src/plugins/config-state.ts:181`.

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: b434621}

Thanks for picking this up and wiring it back to #44180.

I reproduced the original WSL2 failure locally (os.networkInterfaces() throwing uv_interface_addresses returned Unknown system error 1), and the guard/fallback approach in this PR matches the local workaround that got gateway status, status, and pairing-related paths working again.

From a quick pass over the current CI failures, most of the red checks do not appear to be in the files touched here. This PR changes only:

• src/gateway/net.ts
• src/gateway/net.test.ts
• src/infra/tailnet.ts
• src/infra/infra-runtime.test.ts
• src/pairing/setup-code.ts
• src/pairing/setup-code.test.ts

But several reported failures seem to come from other areas (for example auth-profile mocks, outbound/media-local-roots mocks, command-registry initialization, and a TUI gateway port assertion), plus the separate secrets audit job. So at least from the outside, this looks more like unrelated CI noise / baseline instability than a problem caused by the WSL interface-guard change itself.

In short: the fix direction here looks right and it lines up with the behavior reported in #44180.

Thanks for picking this up.

For attribution and validation context: this issue was originally diagnosed from a real WSL2 machine on my side, where os.networkInterfaces() was throwing uv_interface_addresses and breaking the gateway/status/tailnet/pairing paths discussed in #44180.

I also re-tested this on the latest origin/main after my initial local workaround, and the underlying problem still reproduces there without the guard.

I then applied the same source-level fix locally on top of the latest main, rebuilt, and re-verified it with both runtime checks and targeted tests:

• openclaw status
• openclaw gateway probe --timeout 10000
• src/gateway/net.test.ts
• src/pairing/setup-code.test.ts
• src/infra/infra-runtime.test.ts

Everything passed locally after the guard was added.

I also preserved the fix on my fork here in case it helps with follow-up validation or if this PR needs additional evidence:
https://github.com/QuinnRuth/openclaw/tree/wsl-networkinterfaces-guard-fix