Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

MCP endpoint matches the Authorization scheme case-sensitively and logs the same reason for "absent" and "wrong scheme" (ChatGPT connector gets missing_bearer_token)

Open Beginner friendly
  • Is something wrong?
#23,710 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@shethshlok is already working on this.

Since Oct 22, 2026.

  • #23782 by @Rish-it — open
  • #23792 by @shethshlok — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
70/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
backend

Research direction

Start in the apps/server MCP HTTP middleware that parses the Authorization header, then inspect its existing 401 handling and warning reasons. Reproduce the reported lowercase bearer request and the request with no header; done means scheme matching follows the case-insensitive expectation and the two failure reasons are distinguishable without logging credentials.

Written by the indexing model from the issue text.

Description

bug needs-triage
Before submitting
  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.
Area

apps/server

Steps to reproduce

Control (dummy, non-secret value, through the public managed host)

  • Authorization: Bearer <dummy> -> 401, reason unknown_or_expired_token (the header passes the tunnel and reaches verification)
  • Authorization: bearer <dummy> -> 401, reason missing_bearer_token
Expected behavior
  1. Match the scheme case-insensitively.
  2. Log distinct reasons (for example missing_authorization_header vs unsupported_scheme), without logging the credential.
Actual behavior

Summary
The MCP HTTP middleware only accepts an Authorization value that starts with exactly "Bearer " (case-sensitive). RFC 9110 section 11.1 says the auth-scheme is case-insensitive. A lowercase "bearer <token>" is rejected with 401 and the warning reason "missing_bearer_token", which is also the reason logged when no header is sent at all, so the two cases cannot be told apart in the logs.

Why I noticed
ChatGPT custom MCP app (OAuth/DCR, orchestration:read only). OAuth completes: register 201, approval, /oauth/mcp/token 200 with token_type "Bearer". But every /mcp POST from the ChatGPT connector (UA Python/aiohttp), 8 of 8 across two separate authorizations, including one 0.8 s after token issuance and several after "Update tools", is rejected with missing_bearer_token, and the token-verification step never runs. From T3's logs I cannot tell whether ChatGPT sends no Authorization header or a scheme/case T3 does not accept. This may well be OpenAI-side; if so, this issue is only about the two T3 points under Expected behavior.

No credentials, environment IDs or hostnames are included.

Impact

Minor bug or occasional failure

Version or commit

T3 Code Desktop (stable) 0.1.1

Environment

macOS arm64, T3 Code Desktop 0.1.1, main server on 3773, reached through the managed tunnel host

Logs or stack traces
Screenshots, recordings, or supporting files

No response

Workaround

No response

Dominant language
TypeScript
Stars
24.8k
Forks
6.4k
Avg merge
4h 35m
Merged PRs (30d)
174

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pingdotgg/t3code

All issues in pingdotgg/t3code

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.