ux(mcp): unauthed workspace is silent at connect — probe credentials at initialize and warn loudly in the banner #88

New issue

Closed

opened 2026-07-15 14:45:20 +00:00 by hexajon · 0 comments

hexajon commented

2026-07-15 14:45:20 +00:00

(Migrated from codeberg.org)

Problem

When the MCP server launches in an unauthed workspace, I get zero signal at connect time. The failure only surfaces when the first credential-needing tool call fails with not configured - run 'madtea auth login' first - potentially deep into a session, after the agent has already planned work around the tools. Concrete case (2026-07-15): I was in an unauthed scratch clone, tried one madt_api_call, hit the error, and the whole task detoured through CLI shell-outs (see #87).

The channel for exactly this already exists: repoContextBanner (internal/mcp/server.go:339) is the runtime-derived line appended to the server instructions at initialize, built to tell the agent its cwd context "with zero tool calls". Today it reports git-repo/owner/branch — and in this failure mode it happily implies madt_* target this repo while every API-plane tool is dead on arrival. It reports the repo plane but never probes the credential plane.

Ask

Probe credential resolution at initialize and put the result in the banner:

Run the same resolution chain the tools will use (config.GetCredentialsWithSource / the ADR 0025 chain) against the launch dir at server construction.
Unauthed: a LOUD banner line — e.g. ⚠ NOT AUTHENTICATED for this workspace: API tools (issues, prs, api_call, …) will fail. Fix: run 'madtea auth login' in <dir>. Local git tools still work. — so both the agent and I (instructions are visible via /mcp) know at open, not at call N.
Authed: at most a terse confirmation (host + source, e.g. authenticated to codeberg.org (secure backend)); never the URL form that could carry user-info, matching the banner's existing no-token-leak rule.
While in there, make the per-call error name the launch dir too (not configured for <dir> - run 'madtea auth login' there), since that error is what an agent sees mid-session.

Safety notes: the probe must only report source/host, never token material; a probe failure must not block serve startup (degrade to today's behavior).

Future enhancement, filed separately: an in-MCP auth path so the fix doesn't require leaving the harness — see the companion issue.

Acceptance

madtea serve initialized in an unauthed git repo → instructions contain the warning line naming the remedy and the dir.
Initialized in an authed repo → no warning (terse confirmation at most).
No credential-bearing string can reach the banner (test alongside the existing banner tests).

Refs #70 (loudness of MCP errors to me), #87 / #59 (the session this bit).

## Problem When the MCP server launches in an unauthed workspace, I get **zero signal at connect time**. The failure only surfaces when the first credential-needing tool call fails with `not configured - run 'madtea auth login' first` - potentially deep into a session, after the agent has already planned work around the tools. Concrete case (2026-07-15): I was in an unauthed scratch clone, tried one `madt_api_call`, hit the error, and the whole task detoured through CLI shell-outs (see #87). The channel for exactly this already exists: `repoContextBanner` (internal/mcp/server.go:339) is the runtime-derived line appended to the server instructions at initialize, built to tell the agent its cwd context "with zero tool calls". Today it reports git-repo/owner/branch — and in this failure mode it happily implies `madt_* target this repo` while every API-plane tool is dead on arrival. It reports the repo plane but never probes the credential plane. ## Ask Probe credential resolution at initialize and put the result in the banner: - Run the same resolution chain the tools will use (`config.GetCredentialsWithSource` / the ADR 0025 chain) against the launch dir at server construction. - **Unauthed:** a LOUD banner line — e.g. `⚠ NOT AUTHENTICATED for this workspace: API tools (issues, prs, api_call, …) will fail. Fix: run 'madtea auth login' in <dir>. Local git tools still work.` — so both the agent and I (instructions are visible via /mcp) know at open, not at call N. - **Authed:** at most a terse confirmation (host + source, e.g. `authenticated to codeberg.org (secure backend)`); never the URL form that could carry user-info, matching the banner's existing no-token-leak rule. - While in there, make the per-call error name the launch dir too (`not configured for <dir> - run 'madtea auth login' there`), since that error is what an agent sees mid-session. Safety notes: the probe must only report source/host, never token material; a probe failure must not block serve startup (degrade to today's behavior). Future enhancement, filed separately: an in-MCP auth path so the fix doesn't require leaving the harness — see the companion issue. ## Acceptance - `madtea serve` initialized in an unauthed git repo → instructions contain the warning line naming the remedy and the dir. - Initialized in an authed repo → no warning (terse confirmation at most). - No credential-bearing string can reach the banner (test alongside the existing banner tests). Refs #70 (loudness of MCP errors to me), #87 / #59 (the session this bit).

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#88

No description provided.

Rows
Columns