fix(tui): follow active gateway port by haishmg · Pull Request #73338 · openclaw/openclaw

haishmg · 2026-04-28T06:30:59Z

Summary

Problem: openclaw tui could still build its default local Gateway URL from config/defaults after a Gateway was started with an explicit runtime --port.
Why it matters: local TUI users with a custom active Gateway port had to pass --url manually or the client tried ws://127.0.0.1:18789.
What changed: Gateway lock metadata now records the resolved runtime port, and TUI reads that live lock for local default connections before building the loopback URL.
What did NOT change (scope boundary): explicit --url, remote Gateway config, auth selection, and non-loopback websocket security precedence are preserved.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes [Bug]: openclaw tui does not honor the active Gateway runtime port and still targets 18789 #42461
This PR fixes a bug or regression

Root Cause (if applicable)

Root cause: the TUI connection resolver built its local loopback URL from config/defaults and had no process-local source for the already-running Gateway's CLI --port override.
Missing detection / guardrail: no regression test asserted that a Gateway running on 48789 makes default openclaw tui connect to ws://127.0.0.1:48789.
Contributing context (if known): the Gateway already used a per-config lock for active runtime ownership, but the lock payload did not include the resolved port.

Regression Test Plan (if applicable)

Coverage level that should have caught this:
- Unit test
- Seam / integration test
- End-to-end test
- Existing coverage already sufficient
Target test or file: src/tui/gateway-chat.test.ts, src/infra/gateway-lock.test.ts
Scenario the test should lock in: active lock port 48789 drives default TUI URL resolution while explicit --url and remote config still win.
Why this is the smallest reliable guardrail: it tests the lock metadata seam and the TUI resolver directly without starting a real Gateway process.
Existing test that already covers this (if any): none.
If no new test is added, why not: N/A

User-visible / Behavior Changes

openclaw tui without --url now follows the active local Gateway runtime port recorded by the running Gateway.

Diagram (if applicable)

Before:
openclaw gateway --port 48789 -> openclaw tui -> ws://127.0.0.1:18789

After:
openclaw gateway --port 48789 -> active lock records 48789 -> openclaw tui -> ws://127.0.0.1:48789

Security Impact (required)

New permissions/capabilities? No
Secrets/tokens handling changed? No
New/changed network calls? No
Command/tool execution surface changed? No
Data access scope changed? No
If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

OS: macOS local dev
Runtime/container: Node 22 / pnpm via npm exec
Model/provider: N/A
Integration/channel (if any): TUI + local Gateway
Relevant config (redacted): local Gateway mode

Steps

Start the Gateway with a non-default port such as openclaw gateway --port 48789.
Run openclaw tui without --url.
Inspect the resolved Gateway connection target.

Expected

TUI connects to ws://127.0.0.1:48789.

Actual

Before this fix, TUI could connect to ws://127.0.0.1:18789.

Evidence

Failing test/log before + passing after
Trace/log snippets
Screenshot/recording
Perf numbers (if relevant)

Human Verification (required)

Verified scenarios:
- CI=true OPENCLAW_LOCAL_CHECK=0 npm exec [email protected] -- test src/tui/gateway-chat.test.ts src/infra/gateway-lock.test.ts
- npm exec [email protected] -- exec oxfmt --check src/infra/gateway-lock.ts src/infra/gateway-lock.test.ts src/tui/gateway-chat.ts src/tui/gateway-chat.test.ts docs/cli/tui.md docs/gateway/troubleshooting.md
- CI=true OPENCLAW_LOCAL_CHECK=0 npm exec [email protected] -- run check:changed
Edge cases checked: explicit URL override wins; remote Gateway config wins; stale/non-Gateway lock owner is ignored.
What you did not verify: a manual live TUI session against a real Gateway process.

Review Conversations

I replied to or resolved every bot review conversation I addressed in this PR.
I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

Backward compatible? Yes
Config/env changes? No
Migration needed? No
If yes, exact upgrade steps: N/A

Risks and Mitigations

Risk: stale lock metadata could point TUI at the wrong port.
- Mitigation: the reader only trusts a lock whose owner still appears alive as a Gateway and whose recorded port is busy; explicit --url remains the override.

Maintainer Verification - 2026-05-30

Behavior addressed: default openclaw tui Gateway resolution follows the active local Gateway lock port when a Gateway is running on a non-default port.

Real environment tested: macOS source checkout at 4f4b04875ad, isolated OpenClaw home/state, Gateway auth mode none, loopback Gateway on 48789.

Exact steps or command run after this patch:

node --import tsx src/entry.ts gateway run --dev --allow-unconfigured --auth none --bind loopback --port 48789 --ws-log compact --verbose
node --import tsx --input-type=module   # imported src/tui/gateway-chat.ts, called resolveGatewayConnection({}), GatewayChatClient.connect({}), waitForReady(), getGatewayStatus()

Evidence after fix:

process title: openclaw-gateway
resolved_url=ws://127.0.0.1:48789
connected_url=ws://127.0.0.1:48789
gateway_status=ok
[ws] connect client=openclaw-tui clientDisplayName=openclaw-tui version=2026.5.30 mode=ui platform=darwin auth=none localPort=48789

Observed result after fix: the TUI Gateway client resolved and connected to the custom active Gateway port 48789, then successfully called status.

What was not tested: full human keystroke rendering inside the terminal UI; this proof covers the TUI Gateway connection/resolver path and real WebSocket handshake, not terminal paint behavior.

Real behavior proof - Maintainer verification 2026-05-30

Behavior addressed: default openclaw tui Gateway resolution follows the active local Gateway lock port when a Gateway is running on a non-default port.

Real environment tested: macOS source checkout at 4f4b04875ad, isolated OpenClaw home/state, Gateway auth mode none, loopback Gateway on 48789.

Exact steps or command run after this patch:

node --import tsx src/entry.ts gateway run --dev --allow-unconfigured --auth none --bind loopback --port 48789 --ws-log compact --verbose
node --import tsx --input-type=module   # imported src/tui/gateway-chat.ts, called resolveGatewayConnection({}), GatewayChatClient.connect({}), waitForReady(), getGatewayStatus()

Evidence after fix:

process title: openclaw-gateway
resolved_url=ws://127.0.0.1:48789
connected_url=ws://127.0.0.1:48789
gateway_status=ok
[ws] connect client=openclaw-tui clientDisplayName=openclaw-tui version=2026.5.30 mode=ui platform=darwin auth=none localPort=48789

Observed result after fix: the TUI Gateway client resolved and connected to the custom active Gateway port 48789, then successfully called status.

What was not tested: full human keystroke rendering inside the terminal UI; this proof covers the TUI Gateway connection/resolver path and real WebSocket handshake, not terminal paint behavior.

haishmg · 2026-04-28T06:31:35Z

Implemented the #42461 fix in 11a3eb9b6a: local Gateway locks now record the resolved runtime port, and openclaw tui uses that active lock port for default local connections while preserving explicit --url and remote config precedence.

Local verification:

CI=true OPENCLAW_LOCAL_CHECK=0 npm exec [email protected] -- test src/tui/gateway-chat.test.ts src/infra/gateway-lock.test.ts
npm exec [email protected] -- exec oxfmt --check src/infra/gateway-lock.ts src/infra/gateway-lock.test.ts src/tui/gateway-chat.ts src/tui/gateway-chat.test.ts docs/cli/tui.md docs/gateway/troubleshooting.md
CI=true OPENCLAW_LOCAL_CHECK=0 npm exec [email protected] -- run check:changed

@codex review

greptile-apps · 2026-04-28T06:33:35Z

Greptile Summary

This PR fixes a bug where openclaw tui would build its default local Gateway URL from config/defaults instead of the active runtime port when the Gateway was started with an explicit --port. The fix adds a port field to the Gateway lock payload and introduces readActiveGatewayLockPort, which verifies the lock owner is still a live Gateway process before trusting the recorded port. The TUI resolver reads this lock for the default local-mode connection before building the loopback URL, while explicit --url and remote configs correctly take precedence.

Confidence Score: 5/5

This PR is safe to merge — the logic is correct, precedence rules are preserved, and the new seam is well-tested.

No P0 or P1 findings. The implementation correctly handles all stated precedence rules (explicit --url wins, remote mode wins, unknown/dead lock owners return undefined). The port probe and process-cmdline liveness checks are correctly composed. Tests cover the happy path, the cmdline-mismatch staleness case, the --url override, and the remote-mode bypass.

No files require special attention.

_{Reviews (1): Last reviewed commit: "fix(tui): follow active gateway port" | Re-trigger Greptile}

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 11a3eb9b6a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

haishmg · 2026-04-28T06:39:47Z

Pushed ba1903819f to address the Codex startup-window review.

Changes since the first pass:

readActiveGatewayLockPort now verifies the lock owner without requiring the recorded port to be bound yet, so openclaw tui can follow a just-started custom-port gateway during startup.
TUI connection resolution now injects the active lock port through the gateway connection resolver, so a stale OPENCLAW_GATEWAY_PORT cannot override the active local Gateway lock.
Added regressions for both cases.

Local verification:

CI=true OPENCLAW_LOCAL_CHECK=0 npm exec [email protected] -- test src/tui/gateway-chat.test.ts src/infra/gateway-lock.test.ts
npm exec [email protected] -- exec oxfmt --check src/infra/gateway-lock.ts src/infra/gateway-lock.test.ts src/tui/gateway-chat.ts src/tui/gateway-chat.test.ts docs/cli/tui.md docs/gateway/troubleshooting.md
CI=true OPENCLAW_LOCAL_CHECK=0 npm exec [email protected] -- run tsgo:all
CI=true OPENCLAW_LOCAL_CHECK=0 npm exec [email protected] -- run check:changed

@codex review

clawsweeper · 2026-04-28T06:43:02Z

Codex review: needs changes before merge. Reviewed July 6, 2026, 12:18 AM ET / 04:18 UTC.

Summary
The PR records the Gateway runtime port in lock metadata, verifies live Gateway ownership, uses that active local port as the default TUI fallback, updates process-title detection, tests, and TUI docs.

PR surface: Source +45, Tests +108, Docs +3. Total +156 across 8 files.

Reproducibility: yes. Source inspection of the PR head shows a malformed non-empty OPENCLAW_GATEWAY_PORT skips active-lock lookup, while the shared resolver contract ignores malformed/out-of-range env ports and falls back to config/default; I did not run a live two-terminal repro in this read-only review.

Review metrics: 1 noteworthy metric.

Gateway Target Precedence: 1 local fallback rule added. The PR changes how default TUI chooses between explicit targets, config/defaults, and active lock metadata, so precedence correctness matters before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #42461
Summary: This PR is the active candidate fix for the canonical TUI custom Gateway runtime-port bug; an older lock-port PR was closed as superseded.

Members:

canonical: [Bug]: openclaw tui does not honor the active Gateway runtime port and still targets 18789 #42461 - The issue reports default openclaw tui targeting 18789 instead of an active Gateway started on a custom port, and this PR lists it as a closing reference.
superseded: fix(gateway): include port in lock file payload [AI-assisted] #43752 - That closed-unmerged PR added lock port metadata only; the ClawSweeper comment and current PR history show this PR superseded it with schema/readback plus TUI consumption.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🦞 diamond lobster
Patch quality: 🦐 gold shrimp
Result: needs maintainer review before merge.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

[P2] Fix the parsed env-port gate and add the malformed/out-of-range OPENCLAW_GATEWAY_PORT regression while preserving valid env port precedence.

Risk before merge

[P1] Merging as-is can still send openclaw tui to config/default port 18789 when a malformed or out-of-range OPENCLAW_GATEWAY_PORT is inherited, even though the verified active lock points at a custom running Gateway port.
[P1] This PR changes Gateway target precedence for default TUI connections, so the valid explicit --url, OPENCLAW_GATEWAY_URL, valid OPENCLAW_GATEWAY_PORT, and remote-config precedence contract must stay covered before merge.

Maintainer options:

Fix Parsed Env-Port Gate (recommended)
Before merge, make OPENCLAW_GATEWAY_PORT suppress active-lock lookup only when the same parser used by Gateway port resolution accepts the value, and add a focused regression test.
Accept Raw Env Presence
Maintainers could intentionally decide that any non-empty OPENCLAW_GATEWAY_PORT disables active-lock fallback, but that would preserve a known wrong-port failure mode for malformed inherited env.

Copy recommended automerge instruction

@clawsweeper automerge

Special instructions:
Update the TUI Gateway target detection so malformed or out-of-range OPENCLAW_GATEWAY_PORT values do not suppress readActiveGatewayLockPort(); reuse or extract the existing Gateway port env parser instead of duplicating parsing, preserve valid env port precedence, and add regression coverage for invalid env plus active lock port 48789.

Next step before merge

[P2] A narrow mechanical repair can address the remaining parsed env-port blocker on the PR branch without a product decision.

Security
Cleared: Security review cleared: the diff is limited to local Gateway lock metadata, process identity checks, TUI target resolution, tests, and docs with no secret, dependency, CI, package, or broad command-execution changes.

Review findings

[P2] Use parsed port semantics before skipping active lock — src/tui/gateway-chat.ts:354

Review details

Best possible solution:

Keep the lock-backed approach, but make TUI suppress the active-lock fallback only when the explicit env port parses as a valid Gateway port, with regression coverage for malformed and out-of-range env values.

Do we have a high-confidence way to reproduce the issue?

Yes. Source inspection of the PR head shows a malformed non-empty OPENCLAW_GATEWAY_PORT skips active-lock lookup, while the shared resolver contract ignores malformed/out-of-range env ports and falls back to config/default; I did not run a live two-terminal repro in this read-only review.

Is this the best way to solve the issue?

No. The lock-backed owner-boundary fix is the right direction, but the current implementation is incomplete until it uses parsed env-port semantics before suppressing the active Gateway lock fallback.

Full review comments:

[P2] Use parsed port semantics before skipping active lock — src/tui/gateway-chat.ts:354
hasExplicitGatewayTarget treats any non-empty OPENCLAW_GATEWAY_PORT as explicit, but resolveGatewayPort ignores malformed or out-of-range values and falls back to config/default. With an inherited value like 127.0.0.1:not-a-port, TUI skips readActiveGatewayLockPort() and can still connect to 18789 instead of the live 48789 Gateway; use the same parsed-port semantics before suppressing the active-lock lookup. This is the prior ClawSweeper finding still present at the current head.
Confidence: 0.91

Overall correctness: patch is incorrect
Overall confidence: 0.91

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 37f96bde4d90.

Label changes

Label justifications:

P2: This is a normal-priority TUI/Gateway regression fix with a manual --url workaround and limited blast radius.
merge-risk: 🚨 compatibility: The PR changes Gateway target fallback behavior and can still mishandle inherited invalid env port settings during upgrade or local shell reuse.
rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (live_output): Sufficient: the PR includes maintainer live output showing a real isolated Gateway on port 48789, active lock resolution, TUI WebSocket connection to that port, status RPC success, and a tmux TUI reaching gateway connected.
proof: sufficient: Contributor real behavior proof is sufficient. Sufficient: the PR includes maintainer live output showing a real isolated Gateway on port 48789, active lock resolution, TUI WebSocket connection to that port, status RPC success, and a tmux TUI reaching gateway connected.

Evidence reviewed

PR surface:

Source +45, Tests +108, Docs +3. Total +156 across 8 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	4	50	5	+45
Tests	3	110	2	+108
Docs	1	3	0	+3
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	8	163	7	+156

Acceptance criteria:

[P1] pnpm test src/tui/gateway-chat.test.ts src/config/paths.test.ts src/infra/gateway-lock.test.ts.
[P1] pnpm check:changed -- src/tui/gateway-chat.ts src/tui/gateway-chat.test.ts src/config/paths.ts src/config/paths.test.ts src/infra/gateway-lock.ts src/infra/gateway-lock.test.ts.

What I checked:

Current main still lacks the fix: Current main builds the TUI Gateway URL directly from buildGatewayConnectionDetails and the lock payload schema still has no port field, so main does not already solve the linked custom-port TUI problem. (src/tui/gateway-chat.ts:350, 37f96bde4d90)
Latest release still lacks the fix: The v2026.6.11 tag has the same direct TUI URL construction and lock payload shape without a port field. (src/tui/gateway-chat.ts:305, e085fa1a3ffd)
Blocking PR behavior: The PR head treats any trimmed OPENCLAW_GATEWAY_PORT as an explicit target before it decides whether to read the verified active Gateway lock port. (src/tui/gateway-chat.ts:354, 6a1a9bbc31e0)
Resolver contract: resolveGatewayPort parses OPENCLAW_GATEWAY_PORT and falls back to config/default when the env value is malformed or out of TCP bounds; tests already lock in that invalid env values are ignored. (src/config/paths.ts:349, 6a1a9bbc31e0)
Connection builder seam: localPortOverride is the correct narrow seam because it bypasses env URL/port only when supplied, so the remaining bug is deciding when a valid explicit env target exists. (src/gateway/connection-details.ts:43, 6a1a9bbc31e0)
Previous finding still applies: The reviewed tree for src/tui/gateway-chat.ts is unchanged between the prior ClawSweeper-reviewed SHA and the current head, so the prior parsed-port finding was not fixed. (src/tui/gateway-chat.ts:354, 6a1a9bbc31e0)

Likely related people:

steipete: The current PR head is authored by this account, blame attributes the new TUI explicit-target gate to that commit, and older lock history includes this account on gateway-lock work. (role: recent area contributor and PR branch rewrite owner; confidence: high; commits: 6a1a9bbc31e0, d4f895d8f2a4; files: src/tui/gateway-chat.ts, src/infra/gateway-lock.ts, src/cli/gateway-cli/run-loop.ts)
vincentkoc: The PR discussion records a maintainer follow-up and live proof from this account, and the current PR commit carries this account as a co-author on the Gateway/TUI lock-port path. (role: recent PR follow-up owner and adjacent Gateway reviewer; confidence: high; commits: 4f4b04875ad5, 6a1a9bbc31e0; files: src/infra/gateway-lock.ts, src/infra/gateway-process-argv.ts, src/cli/gateway-cli/run-loop.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Review history (2 earlier review cycles)

reviewed 2026-07-03T09:58:09.863Z sha 4f4b048 :: found issues before merge. :: [P1] Preserve env port precedence before merge
reviewed 2026-07-06T03:27:56.785Z sha c936787 :: needs changes before merge. :: [P2] Use parsed port semantics before skipping active lock

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ba1903819f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

haishmg · 2026-04-28T07:30:22Z

Rebased on latest main and addressed the Codex lock-owner review.

Updates:

readActiveGatewayLockPort now requires a verified gateway owner before returning a lock port when cmdline lookup is unavailable.
Added coverage for unverifiable owners on active lock-port reads.
Resolved the troubleshooting docs rebase conflict and formatted docs.

Local verification:

CI=true OPENCLAW_LOCAL_CHECK=0 npm exec [email protected] -- test src/infra/gateway-lock.test.ts src/tui/gateway-chat.test.ts
CI=true OPENCLAW_LOCAL_CHECK=0 npm exec [email protected] -- run format:docs:check
CI=true OPENCLAW_LOCAL_CHECK=0 npm exec [email protected] -- run check:changed

@codex review

chatgpt-codex-connector · 2026-04-28T07:34:14Z

Codex Review: Didn't find any major issues. 🚀

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

haishmg · 2026-04-28T07:40:04Z

Pushed another rebase-stabilization commit: 173282c795.

What changed:

aligned the status fallback expectation with current rebased behavior
isolated src/video-generation/provider-registry.test.ts module imports so larger CI shards cannot leak real capability providers into mocked assertions

Verification:

CI=true OPENCLAW_LOCAL_CHECK=0 npm exec [email protected] -- test src/video-generation/provider-registry.test.ts src/auto-reply/reply/commands-status.thinking-default.test.ts src/infra/gateway-lock.test.ts src/tui/gateway-chat.test.ts
CI=true OPENCLAW_LOCAL_CHECK=0 npm exec [email protected] -- run check:changed

@codex review

chatgpt-codex-connector · 2026-04-28T07:45:17Z

Codex Review: Didn't find any major issues. Keep them coming!

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

haishmg · 2026-04-28T07:49:14Z

Rebased on upstream main and force-pushed fe5e768c35.

Post-rebase verification:

CI=true OPENCLAW_LOCAL_CHECK=0 npm exec [email protected] -- test src/video-generation/provider-registry.test.ts src/auto-reply/reply/commands-status.thinking-default.test.ts src/infra/gateway-lock.test.ts src/tui/gateway-chat.test.ts

@codex review

chatgpt-codex-connector · 2026-04-28T07:54:41Z

Codex Review: Didn't find any major issues. Chef's kiss.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

RomneyDa · 2026-05-29T06:34:26Z

Heads up: this PR needs to be updated against current main before the new required Dependency Guard check can pass.

steipete · 2026-07-06T03:01:31Z

Maintainer rewrite pushed as a28abeb5a46.

The PR now keeps the active custom port in the Gateway-owned lock, verifies the live lock owner before using it, and makes the TUI consume that port only as a local fallback. Explicit --url, OPENCLAW_GATEWAY_URL, OPENCLAW_GATEWAY_PORT, and remote Gateway config still win. The process-identity path is shared with normal single-instance lock acquisition so macOS/BSD process retitling cannot invalidate a live lock.

Proof on Blacksmith Testbox tbx_01kwtmqr63xa3c0mtdka29m0c1 (run):

94 focused tests passed across Gateway lock/process detection, TUI connection resolution, and Gateway run loop.
pnpm check:changed passed for core, core tests, and docs, including production/test typechecks, lint, import-cycle and database-first guards.
pnpm docs:list and docs formatting passed for all 676 docs files.
Real isolated Gateway on port 48789: active lock resolved 48789, TUI resolved ws://127.0.0.1:48789, live status RPC succeeded, and a tmux-driven TUI reached gateway connected.
Fresh isolated autoreview found one process-title/single-instance invariant; fixed with a regression test, then rerun clean with no actionable findings.

Exact-head land-ready update: 6a1a9bb is the clean current-main-plus-reviewed-patch head. Hosted CI run https://github.com/openclaw/openclaw/actions/runs/28767171420 passed at that exact SHA. The rebase changed ancestry only; the tested diff and Testbox/browser/PTY proof above are unchanged. Known proof gaps: none.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c936787ba6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-07-06T03:18:41Z

+  const hasExplicitGatewayTarget = Boolean(
+    urlOverride ||
+    env.OPENCLAW_GATEWAY_URL?.trim() ||
+    env.OPENCLAW_GATEWAY_PORT?.trim() ||


Don't let invalid port env suppress active lock

In environments where OPENCLAW_GATEWAY_PORT is present but invalid or out of range, resolveGatewayPort deliberately ignores it and falls back to config/defaults, but this Boolean still treats the raw value as an explicit target and skips readActiveGatewayLockPort(). That means openclaw tui can again connect to the configured/default port instead of a live Gateway started with --port 48789 whenever a stale/malformed port env var is inherited; please use the same parsed-port semantics before suppressing the active-lock lookup.

Useful? React with 👍 / 👎.

Co-authored-by: haishmg <[email protected]> Co-authored-by: Vincent Koc <[email protected]>

steipete · 2026-07-06T04:27:39Z

Merged via squash.

Prepared head SHA: 6a1a9bbc31e0921abeb4d6c2857ffd4816113b80
Landed commit: cfcdf2a51981531f0694b8235556da28993804df

openclaw-barnacle Bot added docs Improvements or additions to documentation gateway Gateway runtime size: S labels Apr 28, 2026

chatgpt-codex-connector Bot reviewed Apr 28, 2026

View reviewed changes

Comment thread src/infra/gateway-lock.ts Outdated

chatgpt-codex-connector Bot reviewed Apr 28, 2026

View reviewed changes

Comment thread src/infra/gateway-lock.ts

haishmg force-pushed the codex/tui-active-gateway-port-42461 branch from ba19038 to 749091d Compare April 28, 2026 07:30

openclaw-barnacle Bot added size: M and removed size: S labels Apr 28, 2026

haishmg force-pushed the codex/tui-active-gateway-port-42461 branch from 173282c to fe5e768 Compare April 28, 2026 07:42

clawsweeper Bot mentioned this pull request Apr 28, 2026

[Bug]: openclaw tui does not honor the active Gateway runtime port and still targets 18789 #42461

Closed

haishmg force-pushed the codex/tui-active-gateway-port-42461 branch from fe5e768 to a478889 Compare April 28, 2026 14:21

clawsweeper Bot mentioned this pull request Apr 30, 2026

fix(gateway): include port in lock file payload [AI-assisted] #43752

Closed

15 tasks

haishmg force-pushed the codex/tui-active-gateway-port-42461 branch from 7699175 to a7df7bf Compare May 30, 2026 05:21

openclaw-barnacle Bot added the triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. label May 30, 2026

haishmg force-pushed the codex/tui-active-gateway-port-42461 branch from a7df7bf to 95057f5 Compare May 30, 2026 05:26

vincentkoc force-pushed the codex/tui-active-gateway-port-42461 branch from 95057f5 to 4f4b048 Compare May 30, 2026 17:52

openclaw-barnacle Bot added size: S and removed size: M labels Jul 6, 2026

steipete force-pushed the codex/tui-active-gateway-port-42461 branch from a28abeb to c936787 Compare July 6, 2026 03:14

chatgpt-codex-connector Bot reviewed Jul 6, 2026

View reviewed changes

steipete force-pushed the codex/tui-active-gateway-port-42461 branch from c936787 to d87d063 Compare July 6, 2026 03:47

fix(tui): follow active gateway port

6a1a9bb

Co-authored-by: haishmg <[email protected]> Co-authored-by: Vincent Koc <[email protected]>

steipete mentioned this pull request Jul 6, 2026

docs(changelog): credit five Control UI and TUI fixes #100599

Merged

Uh oh!

Uh oh!

Conversation

haishmg commented Apr 28, 2026 • edited by vincentkoc Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Root Cause (if applicable)

Regression Test Plan (if applicable)

User-visible / Behavior Changes

Diagram (if applicable)

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Risks and Mitigations

Maintainer Verification - 2026-05-30

Real behavior proof - Maintainer verification 2026-05-30

Uh oh!

haishmg commented Apr 28, 2026

Uh oh!

greptile-apps Bot commented Apr 28, 2026

Greptile Summary

Confidence Score: 5/5

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

haishmg commented Apr 28, 2026

Uh oh!

clawsweeper Bot commented Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

haishmg commented Apr 28, 2026

Uh oh!

chatgpt-codex-connector Bot commented Apr 28, 2026

Uh oh!

haishmg commented Apr 28, 2026

Uh oh!

chatgpt-codex-connector Bot commented Apr 28, 2026

Uh oh!

haishmg commented Apr 28, 2026

Uh oh!

chatgpt-codex-connector Bot commented Apr 28, 2026

Uh oh!

RomneyDa commented May 29, 2026

Uh oh!

steipete commented Jul 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Jul 6, 2026

Choose a reason for hiding this comment

Uh oh!

steipete commented Jul 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

haishmg commented Apr 28, 2026 •

edited by vincentkoc

Loading

clawsweeper Bot commented Apr 28, 2026 •

edited

Loading

steipete commented Jul 6, 2026 •

edited

Loading