OpenClaw Main Stops Gateway CLI Calls and Status Checks Targeting the Wrong Instance

Two merged OpenClaw CLI fixes close the same operational hazard: a command intended for one Gateway could silently probe or call another instance.

gateway call could ignore an accepted custom local --port, while gateway status could let unrelated host-native service metadata retarget an externally supervised or OCM-selected environment. The result was worse than a clean connection failure: diagnostics or RPC output could be valid for the wrong process.

Both fixes are on main; no supplied release establishes package inclusion. Multi-Gateway, OCM, foreground-development and non-default-port operators should treat target identity as an upgrade acceptance test.

gateway call now honors the local port

PR #119046 fixes direct and parent-inherited forms of the option:

openclaw gateway call health --port 18999 --json
openclaw gateway --port 18999 call health --json

Before the repair, the parent option was accepted but could be ignored in favour of the default or configured target. The child help exposed only --url, whose explicit-credential boundary is deliberately stricter.

The repaired --port path uses the same local resolver as Gateway health: it selects loopback, overrides environment URL/port state and reuses configured local credentials. --url and --port remain mutually exclusive.

Do not “work around” the older bug by putting a token or password in shell history. Use the supported local-port form only after a containing build is identified.

External status keeps external authority

PR #119015 repairs the status path for an externally supervised or explicitly selected Gateway. Native-service command and environment metadata should influence probing only when the active process target is actually that native service.

The upstream example is an OCM environment on a configured port being diagnosed through legacy host service metadata on port 18789. A healthy-looking status in that case says nothing about the selected environment.

Interpretation: service discovery is evidence about a target, not authority to replace the target the operator selected. CLI precedence must preserve explicit process context through status gathering and deep probes.

Why a wrong-target success is dangerous

A call to the wrong Gateway can:

• read configuration, health or session state from another environment;
• mutate the wrong process through a valid RPC;
• make deployment verification pass while the intended instance is dead;
• conceal a stale service still listening on the default port; or
• send credentials across an override path the operator did not intend.

The safe failure is an explicit connection or target error. A successful response from a different Gateway is not partial success.

Acceptance test

Build a disposable topology with two clearly distinct local Gateways:

1. keep one test instance on the default port and one on a non-default port;
2. give each a harmless distinct health or configuration marker;
3. exercise direct and inherited --port forms for gateway call;
4. exercise gateway status from the externally supervised or selected environment;
5. stop the selected test instance and require failure rather than fallback to the other process;
6. confirm --url plus --port is rejected; and
7. inspect process and service metadata to prove no legacy host service changed the selected target.

Use synthetic credentials and loopback only. Do not perform mutating RPCs until the read-only identity check proves the destination.

Automation guidance

Every Gateway automation receipt should include:

• the exact CLI revision;
• target mode (local-port, explicit URL, native service or external supervisor);
• host and port after redaction rules;
• a non-secret instance identity marker; and
• the RPC outcome.

Do not accept “HTTP/WebSocket succeeded” as sufficient evidence. Assert the marker belongs to the intended instance.

Evidence and limits

Official GitHub API data confirms #119046 merged on 4 August and documents built-CLI tests for help, direct/inherited custom ports, unused-port failure and flag conflict. API extraction for #119015 was rate-limited; its chronology and target-precedence claims are grounded in the official merged PR and commit records supplied by the collector.

Relevant collector IDs are 37214/37099/37197 and 37216/37101.

Bottom line

A successful command against the wrong Gateway is a failed operation with misleading evidence. Wait for a containing build, then prove explicit target context survives local-port resolution, external supervision and status probing before re-enabling mutating automation.