Route all MCP clients through a uniform ucode mcp-proxy stdio bridge#201
Open
sunishsheth2009 wants to merge 2 commits into
Open
Route all MCP clients through a uniform ucode mcp-proxy stdio bridge#201sunishsheth2009 wants to merge 2 commits into
ucode mcp-proxy stdio bridge#201sunishsheth2009 wants to merge 2 commits into
Conversation
Every coding agent now registers Databricks MCP servers as one identical local
stdio command — `ucode mcp-proxy --url <endpoint> --host <ws> --profile <p>` —
instead of per-client HTTP-bearer entries. This replaces five divergent auth
paths (claude `${OAUTH_TOKEN}` header, codex `--bearer-token-env-var`, gemini
`--header`, opencode `{env:OAUTH_TOKEN}`, copilot `Bearer ${OAUTH_TOKEN}`), none
of which refreshed the token mid-session, with a single mechanism.
Why a proxy: MCP clients disagree on HTTP-auth config and none expose a
per-request auth hook (except Claude's headersHelper), so a static bearer froze
at launch and expired after ~1h. A local stdio proxy sidesteps all of that: the
client spawns it as a child process (and reaps it — ucode owns no long-lived
process or refresh thread), and the proxy mints a fresh OAuth token from the
Databricks CLI profile on every upstream request. The proxy is an invisible
implementation detail baked into each client's config; users never invoke it.
- src/ucode/mcp_proxy.py (new): stdio<->streamable-HTTP bridge built on the
official `mcp` SDK. `httpx.Auth` injects a fresh `get_databricks_token(...)`
bearer per request; a transport-level pump forwards messages both ways, so new
MCP methods/capabilities pass through untouched.
- cli.py: hidden `ucode mcp-proxy --url --host --profile --use-pat` command.
- databricks.py: `build_mcp_proxy_argv(...)` (mirrors build_auth_token_argv).
- mcp.py: add_{claude,codex,gemini}_mcp_server + opencode/copilot writers now
register the stdio proxy argv; removed build_mcp_http_entry / OAUTH_TOKEN
header. add_claude_mcp_server stays polymorphic so the web_search stdio entry
(a dict with its own env) still registers via add-json.
- pyproject: add `mcp>=1.28.0`.
Verified against a live workspace: `ucode mcp-proxy` handshakes stdio and returns
the endpoint's tools (initialize OK, tools/list OK); ucode's real codex
registration lists the proxy as an enabled stdio server. Tests: 864 pass
(2 pre-existing e2e network failures unrelated); ruff + ty clean.
Co-authored-by: Isaac
This was referenced Jul 9, 2026
Co-authored-by: Isaac
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Replaces the per-client MCP authentication with one uniform mechanism: every coding agent registers Databricks MCP servers as an identical local stdio command —
ucode mcp-proxy --url <endpoint> --host <workspace> --profile <profile>— and a small bridge (shipped in ucode) forwards to the Databricks streamable-HTTP MCP endpoint, minting a fresh OAuth token from the CLI profile on every request.Why
Previously each client got a different HTTP-bearer registration (
Bearer ${OAUTH_TOKEN}header for claude/gemini/copilot,--bearer-token-env-varfor codex,{env:OAUTH_TOKEN}for opencode). The token was frozen at launch and expired (~1h) mid-session, and the clients disagree on auth config with only Claude exposing a per-request hook. This was the source of the inconsistency and the refresh problem raised in review.A stdio proxy resolves all of it in one place:
mcpSDK), rather than depending onuvx uc-mcp-proxyfetched at runtime.Changes
src/ucode/mcp_proxy.py(new) — stdio↔streamable-HTTP bridge. Anhttpx.Authinjects a freshget_databricks_token(...)bearer per request; a transport-level message pump forwards both directions, so new MCP methods/capabilities pass through untouched.cli.py— hiddenucode mcp-proxy --url --host --profile --use-patcommand.databricks.py—build_mcp_proxy_argv(...), mirroringbuild_auth_token_argv.mcp.py—add_{claude,codex,gemini}_mcp_serverand the opencode/copilot config writers now register the stdio proxy argv; removedbuild_mcp_http_entryand the${OAUTH_TOKEN}header wiring.add_claude_mcp_serverstays polymorphic so the existingweb_searchstdio server (a dict entry with its own env) still registers viaadd-json.pyproject.toml— addsmcp>=1.28.0.Verification
Against a live workspace:
ucode mcp-proxycompletes the MCP stdio handshake (initializeOK,tools/listreturns the endpoint's 4 tools); ucode's realcodexregistration lists the proxy as an enabled stdio server with the expected argv. Tests: 864 pass (the 2test_e2e_user_agentfailures are pre-existing, network-dependent, unrelated);ruffandtyclean.Relationship to other PRs
This supersedes the per-client auth approaches:
headersHelper) — the proxy handles Claude refresh uniformly.ucode configure --mcpone-shot flag #199 (ucode configure --mcp) will be rebased onto this so Cursor becomes just another proxy stdio target and--mcpregisters via the proxy.This pull request and its description were written by Isaac.