Skip to content

fix(api): answer /connections per caller, and reload the page on a 401 - #152

Merged
ciaransweet merged 1 commit into
mainfrom
fix/connections-per-caller
Sep 18, 2026
Merged

ciaransweet merged 1 commit into
mainfrom
fix/connections-per-caller

Conversation

@ciaransweet

Copy link
Copy Markdown
Contributor

Closes #127.

  • GET /connections works out supplied for each request, the same way a run resolves credentials, instead of once from the environment. A deployment that sets a per-user header for a signed-in caller (dss's PAT bridge) no longer asks that caller to paste it.
  • Client: every API request, runs included, goes through apiFetch (js/agent-ui/src/session.ts), which reloads the page on a 401, so a sign-in proxy can redirect the visitor to sign in. It won't reload again within 30 seconds, so it can't loop.

Tested locally against dss with its PAT bridge. The 401 reload has no automated test (agent-ui has no JS tests).

Not covered: when oauth2-proxy's own session has expired, it redirects a fetch to the sign-in page instead of returning 401. The browser blocks the cross-origin redirect, so this path never sees a 401.

🤖 Generated with Claude Code

GET /connections worked out `supplied` once, from the process environment.
A deployment that sets a per-user credential header for a signed-in caller
never has it there, so every such caller was told to paste a token the
server was about to supply. It is now resolved for each request, the way a
run resolves credentials.

The client also had no handling for a 401: an expired session silently
started a new thread, or ended a run in `client error`. Every API request,
runs included, now goes through a fetch that reloads the page on a 401, so
whatever sits in front can send the visitor to sign in. It will not reload
again within 30 seconds, so a 401 a reload does not fix cannot loop.

Closes #127

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@ciaransweet
ciaransweet merged commit c55a0fc into main Sep 18, 2026
4 checks passed
@ciaransweet
ciaransweet deleted the fix/connections-per-caller branch September 18, 2026 12:19
ciaransweet pushed a commit that referenced this pull request Sep 18, 2026
🤖 I have created a release *beep* *boop*
---


##
[0.10.1](mcp-toolsets-runtime-v0.10.0...mcp-toolsets-runtime-v0.10.1)
(2026-09-18)


### Features

* **api:** one run per thread, and a signal when it ends
([#153](#153))
([350b21b](350b21b))


### Bug Fixes

* **api:** answer /connections per caller, and reload the page on a 401
([#152](#152))
([c55a0fc](c55a0fc))
* **state:** describe a state handle by its shape, not an example key
([#150](#150))
([163bfac](163bfac))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: ds-release-bot[bot] <116609932+ds-release-bot[bot]@users.noreply.github.com>
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.

A per-user credential the server holds still prompts every visitor, and an expired session reads as a broken chat

1 participant