Greptile Summary

This PR fixes two related local-gateway probe regressions in token-auth mode:

1. Device identity for loopback probes — probe.ts was passing deviceIdentity: undefined for all authenticated probes, meaning the GatewayClient received no identity even when operator scopes required it. The fix makes the IIFE return the loaded identity object instead of undefined, aligning probe behavior with call.ts.
2. Explicit loopback URL budget — resolveProbeBudgetMs previously keyed only on target.kind, so an explicit ws://127.0.0.1:… URL still got the tighter 1500 ms non-local budget. The fix adds an isLoopbackProbeTarget helper that inspects the hostname, and raises the loopback cap from 800 ms to 3000 ms to cover the full detail RPC set.
3. Pre-RPC crash resilience — call.ts called loadOrCreateDeviceIdentity() unconditionally (it could throw in read-only environments). Both probe.ts and call.ts now wrap the call in a try/catch and fall back to deviceIdentity: null, matching the existing probe fallback pattern.

The implementation is clean and the new/updated tests cover the main scenarios well. One minor note: the single catch block in probe.ts (line 58–62) absorbs both URL-parse errors and identity-persistence errors with identical behavior, which could silently hide programming bugs in the identity layer — see the inline comment for a suggested split.

Confidence Score: 4/5

• Safe to merge — no correctness or security regressions found; the only comment is a low-priority error-handling style suggestion.
• All three stated bug fixes are correctly implemented and matched by targeted tests. The one deduction is for the merged catch block in probe.ts that absorbs both URL-parse and identity-persistence errors identically, which could silently hide future bugs in loadOrCreateDeviceIdentity.
• src/gateway/probe.ts — the merged catch block (lines 50–63) is the only area worth a second look.

This is a comment left during a code review.
Path: src/gateway/probe.ts
Line: 50-63

Comment:
**Catch block silently absorbs unrelated errors alongside expected ones**

The single `catch` swallows two distinct error classes:

1. `new URL(opts.url)` throwing — a genuinely unexpected input/programming error (the caller presumably validated the URL).
2. `loadOrCreateDeviceIdentity()` throwing — the documented, expected "read-only dir" case.

Collapsing them into the same `return null` means a future bug inside `loadOrCreateDeviceIdentity` (e.g. a corrupt identity file that throws a JSON parse error) will silently degrade to no-identity instead of surfacing the problem. Consider splitting the two error sites so only the identity-persistence path is intentionally caught:

```
try {
  const hostname = new URL(opts.url).hostname;
  if (isLoopbackHost(hostname) && !(opts.auth?.token || opts.auth?.password)) {
    return null;
  }
} catch {
  return null;
}
try {
  return loadOrCreateDeviceIdentity();
} catch {
  // Read-only or restricted environments should still be able to run
  // token/password-auth detail probes without crashing on identity persistence.
  return null;
}
```

This is low priority since the impact is the same (`null` either way and the probe itself would likely fail for a malformed URL), but it makes the intent clearer and prevents programming errors from being silently absorbed.

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

_{Last reviewed commit: "fix(gateway): restor..."}

Quick CI follow-up:

• All major test lanes are now green on this replacement PR (extensions, contracts, channels, both Linux test shards, compat-node22, and all Windows shards).
• The only failing job in run 23347530484 is check.
• That failure is a formatting check on docs/automation/standing-orders.md, which is outside this PR diff.
• Local pnpm check on this replacement branch passes cleanly.

I also tried to rerun the failed job from my side, but the current token does not have repository-admin rerun permission.

So at this point this looks like an unrelated baseline / merge-ref formatting issue, not a gateway regression in this PR.

Refreshed this PR on top of current main.

What changed in this update:

• merged the current main branch into the PR branch so the PR is mergeable again;
• kept the loopback/device-identity fix intact;
• adapted the loopback probe budget logic to the newer main behavior so active/discovered loopback and explicit loopback URLs honor the caller budget, while inactive discovered loopback stays bounded;
• split the probe.ts URL-parse and device-identity fallback paths, addressing the earlier low-priority Greptile note.

Local verification on the refreshed branch:

• node node_modules/vitest/dist/cli.js run src/gateway/call.test.ts src/gateway/probe.test.ts src/commands/gateway-status/helpers.test.ts
• pnpm check

Both passed locally after syncing dependencies to the current lockfile.

Addressing the latest review note: lightweight probes now keep device identity when auth is present.

Why:

• includeDetails: false should skip detail RPCs, but it should not disable the stored-device-token retry path for authenticated probes.
• In particular, daemon restart / lifecycle reachability checks can call probeGateway(..., includeDetails: false) with token/password auth.

What changed in 4754031:

• removed the detailLevel === "none" early deviceIdentity: null path;
• kept the existing unauthenticated loopback behavior (deviceIdentity: null there still applies);
• added a test covering authenticated lightweight probes.

Local verification after the fix:

• node node_modules/vitest/dist/cli.js run src/gateway/call.test.ts src/gateway/probe.test.ts src/commands/gateway-status/helpers.test.ts
• pnpm check

Quick CI note after the latest follow-up (4754031):

• All major lanes are green again (check, install-smoke, extensions, contracts, channels, both Linux test shards, compat-node22, and all Windows shards).
• The only remaining failure is build-smoke in CI run 23375189118.
• That failure is still the startup-memory check for status --json:
  • current head 4754031: 419.2 MB RSS (limit 400 MB)
  • previous refreshed head 8da0328: 418.7 MB RSS (limit 400 MB)

So the latest lightweight-probe/device-identity follow-up did not introduce a new CI regression; it left the same pre-existing build-smoke / startup-memory overage in place while the rest of the matrix stayed green.

Refreshed this PR on top of the current main again.

Why this refresh:

• the remaining build-smoke failure was on the older status --json cold-start path from the previous base;
• current main now includes fix(status): skip cold-start status probes, which skips the cold-start gateway probe / update path on the lean no-config JSON route and brings status --json startup RSS back down.

Local verification on the refreshed branch:

• node node_modules/vitest/dist/cli.js run src/gateway/call.test.ts src/gateway/probe.test.ts src/commands/gateway-status/helpers.test.ts src/commands/status.scan.fast-json.test.ts
• pnpm check

Both passed locally before pushing this update.

Quick CI follow-up after the latest refresh:

• The previous build-smoke / status --json startup-memory failure is now resolved on this PR.
• The remaining red jobs are:
  • checks (node, test, 2, 2, pnpm canvas:a2ui:bundle && pnpm test)
  • checks-windows (node, test, 6, 6, pnpm test)
• Both fail on the same test outside this PR diff:
  • src/plugin-sdk/subpaths.test.ts
  • plugin-sdk subpath exports > keeps runtime entry subpaths importable
  • Cannot find module .../dist/plugin-sdk/core.js

I also checked current main, and the latest push CI is failing on the same plugin-sdk/subpaths issue as a baseline problem (for example run 23401916155, and the immediately previous main push run 23401283576).

So at this point the gateway-specific CI problem is cleared, and the remaining red looks aligned with current main rather than introduced by this PR.

Addressing the --require-rpc review note:

• daemon status keeps the lightweight connect-only probe by default
• daemon status --require-rpc now goes back to a real status RPC instead of returning success on connect-only hello
• this preserves the fast path for normal status checks while restoring the original require-rpc semantics

I left the default lightweight probe path intact otherwise. The separate ws:// safety concern does not appear to require another daemon-side guard here because GatewayClient.start() still rejects non-loopback plaintext ws:// before connect/auth is sent.

Local validation:

• vitest:
  • src/cli/daemon-cli/probe.test.ts
  • src/cli/daemon-cli/status.test.ts
  • src/cli/daemon-cli/status.gather.test.ts
  • src/cli/daemon-cli.coverage.test.ts
  • src/gateway/probe.test.ts
  • src/gateway/call.test.ts
  • src/commands/gateway-status/helpers.test.ts
• all passed locally

Merged via squash in #51087.

• Prepared head SHA: f8a66ff
• Merge commit: 3cbd4de

Thanks @heavenlost.

Following up on the remaining live Codex comments around daemon-status probe reporting in #51087.

Opened #56282 to tighten that path so lightweight probes surface immediate close reasons instead of waiting for a generic timeout, and so openclaw daemon status prefers a concrete close reason over timeout when both are present.

Follow-up merged.

The daemon-status close-reason cleanup landed in #56282 as commit 0afd73c975af8dafee2f201210ca76c523af4307, from prepared head c356980aa4d8bba5d8c6d92220676ca2c21b38ce.