Skip to content

fix(auth): use Header() instead of APIKeyHeader for WS compat#26

Merged
Leolebleis merged 1 commit intomainfrom
fix/api-key-ws-compat
May 2, 2026
Merged

fix(auth): use Header() instead of APIKeyHeader for WS compat#26
Leolebleis merged 1 commit intomainfrom
fix/api-key-ws-compat

Conversation

@Leolebleis
Copy link
Copy Markdown
Owner

Summary

Brew terminal WS endpoint was 500'ing with `APIKeyHeader.call() missing 1 required positional argument: 'request'`. `fastapi.security.APIKeyHeader` only works on HTTP routes; `Header()` works on both HTTP and WS.

Bonus: Dockerfile now pre-creates `/home/appuser/.claude` so the named volume inherits appuser ownership when Docker first copies it from the image — otherwise the empty mount point is root-owned and `claude login` can't write OAuth tokens.

Test plan

  • Full pytest suite passes (373)
  • `ty check` clean
  • Post-merge: rebuild image, verify WS upgrade returns 101 instead of 500

Security(APIKeyHeader) only works on HTTP routes — its __call__ requires
a Request object that WebSocket routes don't pass, causing a 500 with
"APIKeyHeader.__call__() missing 1 required positional argument: 'request'"
on the terminal WS endpoint. Header() works on both transports.

Trade-off: OpenAPI docs lose the security scheme annotation; auth still
enforced identically.

Also: pre-create /home/appuser/.claude in the image so the named volume
inherits appuser ownership when Docker first populates it from the image.
Without this the empty mount point is root-owned and 'claude login' can't
write OAuth tokens.
@Leolebleis Leolebleis merged commit effc018 into main May 2, 2026
4 checks passed
@Leolebleis Leolebleis deleted the fix/api-key-ws-compat branch May 2, 2026 22:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant