Summary

Fixes #65355.

openclaw gateway probe --timeout 30000 was still capping active non-loopback probes, including gateway.remote.url / configRemote, at 1500ms. This keeps the short budgets for inactive remote probes, inactive local loopback probes, and SSH tunnel probes, but lets active configured or explicit remote probes use the caller's timeout.

Changes

• src/commands/gateway-status/helpers.ts: let active status probe targets use the full caller budget before applying inactive/SSH short caps.
• src/commands/gateway-status/helpers.test.ts: lock the active remote, inactive remote, and SSH tunnel budget cases.
• src/commands/gateway-status.test.ts: prove the gateway probe command passes a 15000ms caller timeout through to the active configured remote probe.

Current main check

Current origin/main still needs this fix: daily_fix.sh check-upstream-fixed reported upstream_fixed=false. After the required sync-main, the PR remains focused on the same three gateway-status files.

Why it matters / User impact

• Why it matters / User impact: Remote gateway users can set a larger timeout for slow but reachable configured gateways without gateway probe reporting a false negative after the old 1500ms background cap.
• What did NOT change: No unrelated gateway server behavior changed; channel delivery, provider/model routing, auth scopes, sessions, retries, config schema, migrations, defaults, inactive remote caps, inactive local caps, and SSH tunnel caps are unchanged.
• Architecture / source-of-truth check: The source-of-truth resolver is resolveProbeBudgetMs() in src/commands/gateway-status/helpers.ts; all configured, explicit, local, and SSH probe targets pass through this canonical budget boundary before probeGateway() receives timeoutMs, and no protocol/schema/default migration is involved.
• Contract surface: gateway.remote.url, CLI --url, and --timeout are existing public surfaces; this PR does not add config fields, change schema validation, change defaults, or migrate stored config.
• Compatibility / defaults: Inactive configured remotes still cap at 1500ms, inactive local loopback still caps at 800ms, and SSH tunnels still cap at 2000ms. Only active configured/explicit targets honor the caller's existing timeout.
• Related open PR scan: This is the existing linked PR for [Bug]: gateway probe false-negatives on remote configRemote because non-loopback targets are hard-capped to 1500ms #65355; check-upstream-fixed after fetching origin/main reported that main has not covered the fix, so this branch remains the implementation candidate rather than a duplicate replacement.
• Out of scope: No changes to probeGateway() protocol handling, WebSocket auth/read scopes, service startup, transport/channel delivery, provider routing, or external network retries.

Real behavior proof

• Behavior or issue addressed: Active configured and explicit remote gateway probe targets now honor the caller timeout instead of being capped at 1500ms, while inactive remote/local and SSH tunnel probe caps remain short.
• Real environment tested: Linux source checkout at current PR head after sync-main, Node v22.22.0, local OpenClaw dev gateway started from this worktree, and a local TCP proxy bound to a non-loopback host address with a 2.2s initial delay before forwarding to the real gateway.
• Exact steps or command run after this patch:

node scripts/test-projects.mjs src/commands/gateway-status.test.ts src/commands/gateway-status/helpers.test.ts

OPENCLAW_REPO="$TASK_WORKTREE" \
OPENCLAW_GATEWAY_PORT=19059 \
OPENCLAW_GATEWAY_TOKEN="<redacted-token>" \
OPENCLAW_READY_TIMEOUT_SECONDS=300 \
OPENCLAW_LOG="$EVIDENCE_DIR/live-gateway-start.log" \
OPENCLAW_DEV_PID_FILE="$EVIDENCE_DIR/live-gateway.pid" \
"$START_OPENCLAW"

python3 -u slow_tcp_proxy.py <non-loopback-local-ip> 19060 127.0.0.1 19059 2.2

node openclaw.mjs gateway probe --timeout 5000 --json --token <redacted-token>
# isolated config: gateway.mode=remote, gateway.remote.url=ws://<non-loopback-local-ip>:19060

• Evidence after fix:

Focused tests after sync:
[test] starting test/vitest/vitest.unit-fast.config.ts
Test Files  1 passed (1)
Tests       17 passed (17)

[test] starting test/vitest/vitest.commands.config.ts
Test Files  1 passed (1)
Tests       25 passed (25)

[test] passed 2 Vitest shards in 52.13s

{
  "command": "node openclaw.mjs gateway probe --timeout 5000 --json --token <redacted-token> (isolated config gateway.mode=remote gateway.remote.url=ws://<non-loopback-local-ip>:19060)",
  "proxyInitialDelayMs": 2200,
  "exitCode": 0,
  "ok": true,
  "targetSummary": [
    {
      "id": "configRemote",
      "kind": "configRemote",
      "active": true,
      "url": "ws://<non-loopback-local-ip>:19060",
      "connect": {
        "ok": true,
        "rpcOk": false,
        "scopeLimited": true,
        "latencyMs": 2250,
        "error": "missing scope: operator.read"
      }
    },
    {
      "id": "localLoopback",
      "kind": "localLoopback",
      "active": false,
      "url": "ws://127.0.0.1:19059",
      "connect": {
        "ok": true,
        "rpcOk": false,
        "scopeLimited": true,
        "latencyMs": 55,
        "error": "missing scope: operator.read"
      }
    }
  ]
}

{
  "command": "node openclaw.mjs gateway probe --timeout 5000 --json --url ws://<non-loopback-local-ip>:19060 --token <redacted-token>",
  "proxyInitialDelayMs": 2200,
  "exitCode": 0,
  "ok": true,
  "targetSummary": [
    {
      "id": "explicit",
      "kind": "explicit",
      "active": true,
      "url": "ws://<non-loopback-local-ip>:19060",
      "connect": {
        "ok": true,
        "rpcOk": false,
        "scopeLimited": true,
        "latencyMs": 2290,
        "error": "missing scope: operator.read"
      }
    }
  ]
}

• Observed result after fix: The active configRemote probe connected through the non-loopback delayed proxy with latencyMs=2250 under a 5000ms caller timeout, so the live path crossed the old 1500ms cap and still succeeded. The explicit remote path also connected at latencyMs=2290. Inactive local loopback remained a short background probe.
• What was not tested: The temporary dev token allowed connection but did not provide operator.read, so the proof verifies live WebSocket reachability/timeout budget rather than full read-status RPC output. No third-party channel, Mantis, Desktop session, or external slow network was used.
• Fix classification: Root cause fix.

Review findings addressed

• RF-001: Addressed by adding redacted live slow-remote gateway probe output above. The proof uses a real OpenClaw gateway from this worktree behind a 2.2s delayed proxy on a non-loopback URL.
• RF-002: Addressed. The live configRemote target is active, non-loopback, and connected with latencyMs=2250 under --timeout 5000; that crosses the old 1500ms cap and exercises the production gateway probe path after the patch.
• RF-003: No separate repair lane is needed; this PR remains the implementation candidate, and no additional automated code repair was requested.

Regression Test Plan

• Maintainer-ready confidence: High. The diff is XS/S-sized, limited to one budget resolver plus two focused regression test files, and current-head verification includes both Vitest coverage and a live slow configRemote probe.
• Coverage level: focused unit and command-level Vitest regression tests plus live local gateway/proxy proof.
• Target test file: src/commands/gateway-status/helpers.test.ts and src/commands/gateway-status.test.ts.
• Scenario locked in: active configured and explicit remote targets receive the caller timeout; inactive remote/local and SSH tunnel probes remain capped.
• Why this is the smallest reliable guardrail: the regression lives at the budget resolver that caused the cap and at the command caller that passes the budget into gateway probes.
• Patch quality notes: The timeout change is not a broad retry increase or fallback. It reorders the canonical budget resolver so active user-selected targets receive the caller's existing timeout, while the previous short caps remain intact for background/inactive probes.

Merge risk

• Risk labels considered: merge-risk: availability.
• Risk explanation: Gateway probe/status availability is affected because this code decides how long CLI diagnostics wait for each target. A wrong change could either keep false negatives for slow active remotes or make background probes wait too long.
• Why acceptable: The branch preserves all inactive and SSH caps, changes only active configured/explicit target budgeting, and verifies the live slow remote path with a 2.2s delayed non-loopback configRemote probe under --timeout 5000.

Root Cause

• Root cause: The root cause was the ordering inside the source-of-truth resolver resolveProbeBudgetMs(): it checked for non-loopback targets before considering whether the target was the active user-selected remote endpoint, causing active configured remote probes to be forced through the legacy 1500ms background-probe cap.
• Why this is root-cause fix: The fix changes the source-of-truth budget resolver so active targets receive the caller budget before inactive/background caps apply; tests cover both the resolver and command-level propagation into gateway probe calls.
• Missing guardrail: Existing tests covered active local loopback using the caller timeout, but encoded active non-loopback targets as capped instead of distinguishing active remote probes from inactive background probes.