#21842: fix(gateway-cli): use wss:// scheme when gatewayTls is enabled
cli
size: XS
Cluster:
Gateway and TLS Enhancements
## Summary
When `gateway.tls.enabled` is set to `true`, the CLI's `--json` output path in the gateway discover command hardcoded `ws://` when building `wsUrl`. This caused a `SECURITY ERROR` because the CLI constructed a plaintext `ws://` URL to a non-loopback address while the gateway was actually listening on `wss://`.
## Root Cause
Single hardcoded scheme in `src/cli/gateway-cli/register.ts`:
```typescript
// Before — always ws://
return { ...b, wsUrl: host ? `ws://${host}:${port}` : null };
```
The correct pattern already existed in `discover.ts` (`renderBeaconLines`), which correctly reads `beacon.gatewayTls` to pick the scheme. The `--json` path simply never got the same treatment.
## Fix
```typescript
// After — respects gatewayTls flag
const scheme = b.gatewayTls ? "wss" : "ws";
return { ...b, wsUrl: host ? `${scheme}://${host}:${port}` : null };
```
## Changes
- `src/cli/gateway-cli/register.ts` — 2-line fix (+1 line)
- `src/cli/gateway-cli/run-loop.test.ts` — 2 new test cases
## Tests
| Scenario | Result |
|---|---|
| `gatewayTls: true` → wsUrl uses `wss://` | ✅ |
| `gatewayTls: false` → wsUrl uses `ws://` | ✅ |
| `gatewayTls: undefined` → wsUrl uses `ws://` | ✅ |
| All 10 existing gateway-cli tests | ✅ |
Fixes #21703
<!-- greptile_comment -->
<h3>Greptile Summary</h3>
Fixes a security bug where the CLI's `gateway discover --json` output hardcoded `ws://` for WebSocket URLs even when TLS was enabled. This caused connection failures because the gateway was listening on `wss://` but the CLI advertised `ws://`.
The fix applies the same `gatewayTls` check that already existed in `discover.ts` (for rendering beacon lines) to the `--json` output path in `register.ts`. The change is minimal (2 lines) and follows the established pattern.
- Fixed: `register.ts` now respects `beacon.gatewayTls` flag when building `wsUrl` for JSON output
- Tests: added coverage for TLS-enabled and TLS-disabled cases (though tests could be improved to exercise actual code path)
<h3>Confidence Score: 5/5</h3>
- This PR is safe to merge with minimal risk
- The fix is a straightforward 2-line change that applies an existing pattern from `discover.ts` to the `--json` output path. The logic is simple (ternary operator to pick scheme based on boolean flag), matches the established codebase pattern, and has test coverage for all cases (TLS enabled, disabled, and undefined). No breaking changes or edge cases.
- No files require special attention
<sub>Last reviewed commit: 0a11115</sub>
<!-- greptile_other_comments_section -->
<!-- /greptile_comment -->
Most Similar PRs
#22682: fix(gateway): [P0] status probe ignores gateway.tls.enabled — hardc...
by mahsumaktas · 2026-02-21
84.8%
#14277: fix(CLI): Use wss for probeUrl, when gateway has tls enabled
by tha80 · 2026-02-11
81.1%
#19026: fix(gateway): use loopback for local CLI-to-gateway connections
by Phineas1500 · 2026-02-17
80.4%
#22716: fix: gateway status probe uses wss:// when TLS enabled; accept self...
by Fratua · 2026-02-21
80.3%
#22056: fix(gateway): use loopback for self-connections regardless of bind ...
by usedhonda · 2026-02-20
79.8%
#21233: docs: clarify bind=lan non-loopback access requires wss or tunnel (...
by saurabhchopade · 2026-02-19
79.8%
#22110: fix(tools): prefer loopback for internal tool-to-gateway RPC calls
by pierreeurope · 2026-02-20
78.8%
#23735: Gateway: add first-class wss validation and remote TLS guidance
by bmendonca3 · 2026-02-22
77.6%
#14564: fix(gateway): crashes on startup when tailscale meets non-loopback ...
by yinghaosang · 2026-02-12
77.2%
#21772: [Bug]: Allow ws:// to Tailscale CGNAT addresses
by AIflow-Labs · 2026-02-20
77.0%