Greptile Summary

This PR extends the existing isLocalDirectRequest loopback-bypass pattern — already applied to canvas requests, session-kill, and WebSocket message handling — to trusted-proxy auth mode. When a connection arrives directly on the loopback interface (no forwarded headers, localish Host), it is granted access with method: "none" before any proxy-header checks, allowing local CLI commands to reach the gateway without proxy identity headers.

Key observations:

• The bypass is placed correctly before the auth.trustedProxy config and trustedProxies list checks, so it also covers misconfigured trusted-proxy setups for local connections.
• The returned { ok: true, method: "none" } is consistent with every other local-direct bypass in the codebase (canvas, session-kill, etc.).
• One subtle edge case: if trustedProxies contains 127.0.0.1 (e.g. a local nginx reverse proxy on the same machine), resolveRequestClientIp resolves to undefined for header-less loopback requests (the proxy IP is trusted but no forwarded chain exists), causing isLocalDirectRequest to return false. The bypass silently doesn't apply and the CLI would fail with trusted_proxy_user_missing. This is a corner case but worth being aware of.
• Test coverage covers the primary IPv4 loopback path and the non-loopback rejection; an IPv6 loopback test (::1) is missing.

Confidence Score: 4/5

• Safe to merge — the change is small, follows an established pattern in the codebase, and cannot be triggered by external connections (TCP remoteAddress must genuinely be loopback).
• The logic is simple and consistent with how isLocalDirectRequest is used elsewhere. The only notable gap is the absence of an IPv6 loopback test, which means confidence in ::1 behavior relies on the correctness of isLoopbackIpAddress rather than an explicit end-to-end test for this bypass path. No functional bugs or security issues were found.
• No files require special attention; the one suggestion is a minor test-coverage improvement in src/gateway/auth.test.ts.

This is a comment left during a code review.
Path: src/gateway/auth.test.ts
Line: 653-693

Comment:
**Missing IPv6 loopback test case**

The two new tests only exercise `remoteAddress: "127.0.0.1"`. The gateway also binds to `::1` when available (see `resolveGatewayListenHosts` in `net.ts`), so a CLI that connects via `[::1]` should receive the same bypass. Adding a third test with `remoteAddress: "::1"` and `host: "[::1]:18789"` would confirm the bypass works symmetrically on IPv6 loopback.

```ts
it("allows local direct IPv6 loopback connections to bypass trusted-proxy auth", async () => {
  const res = await authorizeGatewayConnect({
    auth: {
      mode: "trusted-proxy",
      allowTailscale: false,
      trustedProxy: trustedProxyConfig,
    },
    connectAuth: null,
    trustedProxies: ["10.0.0.1"],
    req: {
      socket: { remoteAddress: "::1" },
      headers: {
        host: "[::1]:18789",
      },
    } as never,
  });

  expect(res.ok).toBe(true);
  expect(res.method).toBe("none");
});
```

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

_{Last reviewed commit: "auth: allow local lo..."}

This bypasses trusted-proxy auth entirely for loopback connections, not just calls via the CLI, returning { ok: true, method: "none" }. I'm more inclined to not bypass auth here at all.

The trusted-proxy mode exists so the reverse proxy handles identity for every connection. This creates a path with no identity — no user, no audit trail.

A few concerns:

• If anything on the same box has a Server-Side Request Forgery (SSRF) vulnerability (where an attacker tricks a server into making requests on their behalf), that's an unauthed path straight to the gateway via 127.0.0.1.
• In Docker, the loopback isolation assumption gets fragile fast — shared network namespaces, port mappings, k8s pods.
• method: "none" means these connections have no user attribution. That's going to make debugging in prod harder than it needs to be.

I get that local CLI commands don't go through the proxy and lack identity headers. A local service account token would solve that without opening up a full auth bypass.

Here's how it maps out:

Current state (no PR):

With this PR:

With a local service account token instead:

The token would work similarly to token auth mode but scoped to loopback only — auto-generated, file-permission-restricted (0600), and only valid on local connections. Even if it leaks, it's not usable remotely.

Also can you add a description to the PR @dragonforce2010 ?

Just came across #17746, and this is similar to what I'm proposing.

Closing this as duplicate or superseded after Codex automated review.

Close PR #51070 as superseded by the open service-identity/trusted-proxy RFC #69066. Current main intentionally keeps trusted-proxy loopback requests fail-closed, with tests and docs enforcing that contract, and the PR's blanket method: "none" loopback bypass conflicts with the review discussion's service-account-token direction.

Best possible solution:

Do not merge the blanket loopback method: "none" bypass. Keep the current fail-closed trusted-proxy loopback contract on main, and route the real local/internal-auth problem through the open service-identity RFC #69066 plus any narrower opt-in trusted-proxy fixes that maintain identity, rate limiting, and auditability.

What I checked:

• Current main rejects trusted-proxy loopback sources: authorizeTrustedProxy returns trusted_proxy_loopback_source for loopback remote addresses, and authorizeGatewayConnectCore returns that trusted-proxy failure instead of falling through to token/password or method: "none". (src/gateway/auth.ts:278, 4ad8b613c9b6)
• Regression tests codify fail-closed local-direct behavior: The local-direct trusted-proxy test matrix rejects loopback requests with no credentials, valid token, wrong token, or no local token, all with trusted_proxy_loopback_source; additional tests reject loopback identity headers and forwarded loopback chains. (src/gateway/auth.test.ts:901, 4ad8b613c9b6)
• Public docs require non-loopback trusted proxy source: The trusted-proxy docs state that trusted-proxy auth rejects loopback-source requests, same-host loopback reverse proxies do not satisfy trusted-proxy auth, loopback trusted-proxy auth fails closed, and the security checklist includes 'No loopback proxy source'. Public docs: docs/gateway/trusted-proxy-auth.md. (docs/gateway/trusted-proxy-auth.md:90, 4ad8b613c9b6)
• Configuration docs match the fail-closed contract: The configuration reference says gateway.auth.mode: "trusted-proxy" expects a non-loopback proxy source and that loopback entries in trustedProxies do not make loopback requests eligible for trusted-proxy auth. Public docs: docs/gateway/configuration-reference.md. (docs/gateway/configuration-reference.md:393, 4ad8b613c9b6)
• PR discussion identifies the auth regression: The live PR comments include a reviewer concern that this bypass creates unauthenticated method: "none" loopback access with no user/audit identity and recommends a local service account token instead; the Codex review comment also flags the same same-host proxy/auth regression risk. (c14cd23c503a)
• Open RFC [RFC] Separate internal service identity from user auth in OpenClaw gateway #69066 supersedes this PR: [RFC] Separate internal service identity from user auth in OpenClaw gateway #69066 is open and explicitly lists auth: allow local loopback connections to bypass trusted-proxy auth #51070 in the trusted-proxy hotfix wave, recommends service identity as the durable fix, and says auth: allow local loopback connections to bypass trusted-proxy auth #51070 and fix(gateway): allow local connections in trusted-proxy auth mode #54426 are superseded by Phase 1 and can close with a pointer to the RFC.

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 4ad8b613c9b6.