Greptile Summary

This PR fixes a bug where setting dangerouslyDisableDeviceAuth: true in the gateway Control UI config failed to bypass device identity checks in evaluateMissingDeviceIdentity, resulting in reject-device-required errors for iframe environments that cannot issue device crypto and have no shared token.

Key changes:

• connect-policy.ts: Adds an explicit early-return { kind: "allow" } when isControlUi && controlUiAuthPolicy.allowBypass is true, placed between the existing trustedProxyAuthOk guard and the existing !allowBypass block. This prevents the unintended fall-through to roleCanSkipDeviceIdentity.
• connect-policy.test.ts: Adds two regression tests — one for the exact failing scenario and one for the remote-iframe baseline. All pre-existing tests continue to pass.

The fix is minimal and well-scoped. Token/password auth enforcement remains intact downstream via resolveConnectAuthDecision; only device-identity crypto is bypassed by this flag.

Confidence Score: 4/5

• Safe to merge; the fix is small and correctly targeted, with regression tests for the reported failure case.
• The one-point deduction is for the missing test coverage of the failed-auth state through the bypass path — the PR relies on a downstream function (resolveConnectAuthDecision) to enforce token auth when allowBypass is true, but this is not exercised in the unit tests for evaluateMissingDeviceIdentity. The fix itself is logically correct and the existing tests all pass.
• No files require special attention beyond the noted test coverage gap in connect-policy.ts.

This is a comment left during a code review.
Path: src/gateway/server/ws-connection/connect-policy.ts
Line: 85-89

Comment:
**Missing test for failed-auth state in bypass path**

The new early return skips the `reject-unauthorized` guard at line 103 (which checks `!params.authOk && params.hasSharedAuth`). The PR description asserts that authentication is enforced downstream by `resolveConnectAuthDecision`, but neither of the two new regression tests exercises the case where `allowBypass` is `true` while authentication has failed. Adding a test with a failed-auth state through this bypass path would document the expected behavior and confirm that the downstream guard actually fires, making the security boundary easier to reason about in isolation.

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

_{Last reviewed commit: 9f5da84}

Closing this as implemented after Codex review.

Current main already implements the dangerouslyDisableDeviceAuth bypass for Control UI operator sessions, covers the reported sharedAuthOk=false regression in unit tests, and exercises the behavior in the gateway auth suite. This PR is redundant against main, and its broader unconditional bypass no longer matches the current intentionally operator-scoped behavior.

What I checked:

• Explicit bypass exists on main: evaluateMissingDeviceIdentity now returns { kind: "allow" } for Control UI sessions when controlUiAuthPolicy.allowBypass is true and role === "operator". (src/gateway/server/ws-connection/connect-policy.ts:121, 5f702b464bb5)
• Exact failing case is regression-tested: Unit test covers dangerouslyDisableDeviceAuth: true with no device, sharedAuthOk: false, authOk: false, and expects allow, which matches the bug described in the PR body. (src/gateway/server/ws-connection/connect-policy.test.ts:179, 5f702b464bb5)
• Current main intentionally narrows scope: Adjacent regression test asserts the bypass must not apply to role: "node", showing current main intentionally rejects the PR's broader unconditional bypass shape. (src/gateway/server/ws-connection/connect-policy.test.ts:193, 5f702b464bb5)
• End-to-end gateway coverage exists: Gateway auth suite configures dangerouslyDisableDeviceAuth: true and verifies Control UI connections succeed without device-token enforcement. (src/gateway/server.auth.control-ui.suite.ts:420, 5f702b464bb5)
• Fix commit is on current main: git merge-base --is-ancestor 5f702b464bb5500f3b0739741548c729c9011943 HEAD returned success, so the implementation commit is contained in current main (4e4aeacae4a87f2fe09125d462d88cd71a18cb66). (5f702b464bb5)

So I’m closing this as already implemented rather than keeping a duplicate issue open.

Review notes: reviewed against 4e4aeacae4a8; fix evidence: commit 5f702b464bb5.