Greptile Summary

This PR fixes a regression in trusted-proxy auth mode where ACPX child processes connecting back to the gateway via localhost were incorrectly rejected because they don't carry the expected proxy user header (e.g. x-amzn-oidc-data). The single-line fix inserts a localDirect check after authorizeTrustedProxy fails, returning { ok: true, method: "none", user: "local" } for loopback connections — consistent with how the gateway handles local traffic in non-proxy auth modes.

Key points:

• Logic is correct: isLocalDirectRequest resolves the actual client IP through forwarding headers, so a proxied external request with host: localhost still fails the loopback-address test and cannot exploit this path.
• Early-exit paths are unaffected: The trusted_proxy_config_missing and trusted_proxy_no_proxies_configured guards run before the new check, so a misconfigured deployment does not accidentally open a bypass.
• No test coverage added: The new bypass path is security-sensitive and completely untested. The existing describe("trusted-proxy auth", ...) suite should be extended with at least: a passing local connection case, a proxied request that remains rejected despite a localish host header, and confirmation that the early-exit guards still block local connections when trustedProxies is empty.

Confidence Score: 4/5

• Safe to merge with the understanding that test coverage for the new bypass path should follow in a near-term commit.
• The fix is minimal, targeted, and logically sound. The existing isLocalDirectRequest implementation is robust against header-injection spoofing by external clients, so no new attack surface is introduced. The only concrete gap is the absence of unit tests for the new code path — important for a security-adjacent change but not a blocker given the correctness analysis.
• No files require special attention beyond the missing test cases in src/gateway/auth.test.ts.

This is a comment left during a code review.
Path: src/gateway/auth.ts
Line: 401-403

Comment:
**Missing test coverage for new bypass path**

The new `localDirect` bypass in `trusted-proxy` mode has no corresponding test cases in `auth.test.ts`. This is a security-sensitive code path (it allows requests to skip authentication entirely), and the existing `describe("trusted-proxy auth", ...)` suite doesn't exercise it at all.

At minimum, tests should cover:
- A localhost connection without proxy headers is accepted with `{ method: "none", user: "local" }`.
- A proxied request (correct remote addr, missing user header, `host: localhost`) is still rejected (i.e., `isLocalDirectRequest` returns false for proxied traffic even when `host` is localish).
- The early-exit paths (`trusted_proxy_config_missing`, `trusted_proxy_no_proxies_configured`) still reject local connections (confirming they are intentionally excluded from the bypass).

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(gateway): allow local connections in..." | Re-trigger Greptile}

Closing this as duplicate or superseded after Codex automated review.

Close #54426 as superseded by #69066. The PR addresses real trusted-proxy/internal-caller pain, but current main intentionally fails closed for loopback-source trusted-proxy requests, and #69066 is the open canonical design track for separating internal service identity from user auth rather than merging this broad localDirect bypass.

Best possible solution:

Close #54426 as superseded by #69066. Keep current main's fail-closed trusted-proxy loopback behavior, and pursue a first-class internal service identity or another explicitly gated fallback through the canonical trusted-proxy auth design track rather than merging this blanket localDirect method:none bypass.

What I checked:

• Current trusted-proxy auth fails closed on loopback sources: authorizeTrustedProxy returns trusted_proxy_loopback_source for loopback remote addresses, and authorizeGatewayConnect returns that trusted-proxy failure directly without falling through to method:"none" for localDirect. (src/gateway/auth.ts:278, 6cd047e7c270)
• Regression tests reject this PR's bypass shape: The local-direct trusted-proxy test suite asserts direct loopback requests are rejected with trusted_proxy_loopback_source, including no credentials, a valid token, a wrong token, and no configured local token. (src/gateway/auth.test.ts:901, 6cd047e7c270)
• Docs define non-loopback trusted proxy as the supported boundary: Trusted proxy docs say loopback-source requests are rejected, same-host loopback reverse proxies do not satisfy trusted-proxy auth, and same-host setups should use token/password auth or route through a non-loopback trusted proxy address. Public docs: docs/gateway/trusted-proxy-auth.md. (docs/gateway/trusted-proxy-auth.md:93, 6cd047e7c270)
• Protocol docs keep internal backend relief on shared auth, not trusted-proxy bypass: The protocol docs reserve direct-loopback backend device-less operation for gateway-client backend RPCs authenticated with the shared gateway token/password, while identity-bearing trusted-proxy auth is described as non-loopback. Public docs: docs/gateway/protocol.md. (docs/gateway/protocol.md:113, 6cd047e7c270)
• Canonical superseding item exists: Provided GitHub context for [RFC] Separate internal service identity from user auth in OpenClaw gateway #69066 shows an open RFC specifically separating internal service identity from user auth, listing fix(gateway): allow local connections in trusted-proxy auth mode #54426 among PRs it would supersede or subsume and framing that as the durable fix for trusted-proxy/internal-caller coupling.
• PR discussion identified security risk: The provided review context includes a P1 review warning that unconditional localDirect acceptance can authenticate colocated reverse-proxy traffic without verified internal caller identity, matching current main's fail-closed implementation and docs. (src/gateway/auth.ts:401, f45ff858edd1)

So I’m closing this here and keeping the remaining discussion on the canonical linked item.

Codex Review notes: model gpt-5.5, reasoning high; reviewed against 6cd047e7c270.