Bug type

Regression (worked before, now fails)

Summary

When the Gateway is started on a custom port such as 48789, openclaw tui can still try to connect to the default local port 18789. This happens because the TUI
connection path resolves its Gateway URL from config/defaults without first applying the active runtime port override.

The fix is to apply applyGatewayRuntimePortEnvOverride() before resolving the TUI Gateway connection target, so openclaw tui automatically follows the currently r
unning Gateway listener port. A regression test should verify that when the active runtime port is 48789, TUI resolves ws://127.0.0.1:48789.

Steps to reproduce

Steps to reproduce:

1. Start the Gateway on a custom port:

openclaw gateway --port 48789

2. In another terminal, run:

openclaw tui

3. Observe that TUI tries to connect to the default Gateway port 18789 instead of the active runtime port 48789.
4. Confirm the Gateway is actually listening on 48789:

openclaw gateway status --deep

Expected result:
openclaw tui should automatically connect to ws://127.0.0.1:48789.

Actual result:
openclaw tui targets ws://127.0.0.1:18789 unless --url is passed manually.

Expected behavior

no

Actual behavior

• openclaw tui does not follow the active local Gateway runtime port.
  • When the Gateway is running on a custom port such as 48789, TUI still targets the default local port 18789.
  • The TUI connection fails unless the user manually passes --url ws://127.0.0.1:48789.
  • This is inconsistent with other Gateway-aware CLI flows that already honor the active runtime port.

OpenClaw version

2026.3.8

Operating system

docker

Install method

docker

Model

no

Provider / routing chain

no

Config file / key location

No response

Additional provider/model setup details

We fixed the two issues like this:

1. Fixed openclaw tui still targeting the default port 18789
   We added applyGatewayRuntimePortEnvOverride() at the start of resolveGatewayConnection() in src/tui/gateway-chat.ts:269.
   This makes TUI apply the active Gateway runtime port before building the local Gateway URL. If the running Gateway is listening on 48789, TUI now resolves
   ws://127.0.0.1:48789 instead of falling back to 18789.
2. Added regression coverage and documentation so the behavior stays correct
   We added a regression test in src/tui/gateway-chat.test.ts:151 that covers the case where the active runtime Gateway port is 48789, and verifies that TUI
   connects to 48789.
   We also updated the docs in:

• docs/cli/tui.md
• docs/gateway/troubleshooting.md

The docs now explicitly say that openclaw tui follows the active local Gateway runtime port, so custom listener ports such as 48789 are handled automatically.

troubleshooting.md
tui.md

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

We fixed the two issues like this:

1. Fixed openclaw tui still targeting the default port 18789
   We added applyGatewayRuntimePortEnvOverride() at the start of resolveGatewayConnection() in src/tui/gateway-chat.ts:269.
   This makes TUI apply the active Gateway runtime port before building the local Gateway URL. If the running Gateway is listening on 48789, TUI now resolves
   ws://127.0.0.1:48789 instead of falling back to 18789.
2. Added regression coverage and documentation so the behavior stays correct
   We added a regression test in src/tui/gateway-chat.test.ts:151 that covers the case where the active runtime Gateway port is 48789, and verifies that TUI
   connects to 48789.
   We also updated the docs in:

• docs/cli/tui.md
• docs/gateway/troubleshooting.md

The docs now explicitly say that openclaw tui follows the active local Gateway runtime port, so custom listener ports such as 48789 are handled automatically.

troubleshooting.md
tui.md