Activity

1. tulshi

   added

   bugSomething isn't workingSomething isn't working

   on Sep 9, 2026
2. kocaemre commented on Sep 9, 2026

   

   kocaemre

   on Sep 9, 2026

   More actions

   I prepared a narrow, signed branch for this issue, following the repo rule that maintainers open PRs here rather than outside contributors opening one directly.

   Branch/compare:

   • kocaemre:v2/fix/2297-401-response-body
   • https://github.com/modelcontextprotocol/inspector/compare/v2/main...kocaemre:inspector:v2/fix/2297-401-response-body?expand=1
   • commit: 8e9766fb (fix: log intercepted auth response bodies, DCO signed off)

   What changed:

   • keeps auth-challenge interception behavior unchanged;
   • moves fetch tracking below the 401/403 auth interceptor for intercepted transport fetches, so the Monitor network log records the response status, WWW-Authenticate header, and async responseBody before AuthChallengeError is thrown;
   • keeps long-lived stream body safeguards intact via the existing fetch tracker;
   • adds a regression covering a Streamable HTTP 401 with WWW-Authenticate and JSON body.

   Validation in this environment:

   cd clients/web && npm run test -- --run src/test/core/mcp/nodeTransportFetchTracking.test.ts
   # PASS: 1 file, 1 test
   
   npm exec -- eslint core/mcp/node/transport.ts clients/web/src/test/core/mcp/nodeTransportFetchTracking.test.ts --max-warnings 0
   # PASS
   
   cd clients/web && npm run format:check -- src/test/core/mcp/nodeTransportFetchTracking.test.ts
   # PASS
   
   npm run format:check:core
   # PASS
   
   cd clients/web && npm run build
   # PASS: tsc -b, vite build, tsup runner build
   
   git diff --check upstream/v2/main..HEAD
   # PASS

   No PR opened from my side per the repo's maintainer-opened PR flow.
3. cliffhall

   added

   v2Issues and PRs for v2Issues and PRs for v2

   on Sep 11, 2026
4. cliffhall commented on Sep 11, 2026

   

   cliffhall

   on Sep 11, 2026

   Member

   More actions

   Triage: Priority Medium (total 6)

   • Severity 3 — a real diagnostic surface is missing: the 401 response body (and with it the OAuth Protected Resource Metadata / scope detail) never reaches the log, so OAuth debugging is partial
   • Urgency 2 — wanted, but nothing is blocked on it and the browser network panel is a workaround
   • Bonuses: +1 bug label

   Board: #28, Status Incoming (awaiting maintainer review — no milestone yet).

   Note: a prototype branch is offered in the thread above. Per CONTRIBUTING.md a maintainer will implement this against v2/main rather than pulling the branch.
5. cliffhall

   added this to the v2.7.0 milestone on Sep 11, 2026
6. cliffhall

   self-assigned this

   on Sep 14, 2026
7. cliffhall

   added 2 commits that reference this issue on Sep 14, 2026

   fix: bound the 401/403 body read so an unending body is released (#2297)

   ...

   a7c4c52

   fix: enforce the challenge body cap per byte and never log cut-off JS…

   ...

   1fd1b15
8. cliffhall commented on Sep 14, 2026

   

   cliffhall

   on Sep 14, 2026

   Member

   More actions

   Fixed by #2371, merged to v2/main. The network log now records an intercepted 401/403's status, WWW-Authenticate header and response body, on both the direct (CLI/TUI) and web paths.
9. cliffhall

   closed this as completedon Sep 14, 2026
10. cliffhall

    linked a pull request that will close this issuefix: record an intercepted 401's status, headers and body in the network log #2371on Sep 14, 2026
11. pull

    added a commit that references this issue on Sep 16, 2026

    fix: record an intercepted 401's status, headers and body (modelconte…

    ...

    af4b574