`serve`/daemon path launches the system browser on 401 with no way to suppress it (`MCPORTER_OAUTH_NO_BROWSER` is auth-command-only)

[vitalijssilins]

Motivation

We run mcporter as the single MCP bridge for coding agents (Claude Code / Codex): one user-scope mcporter serve --stdio entry exposing ~9 remote servers. It works great — except when a token expires mid-session.

When any bridged tool call hits a 401, the daemon runs the interactive OAuth flow and unconditionally launches the system browser. From the user's perspective a browser tab steals focus mid-task with zero context about which server wants auth or why. In an agent harness the desired flow is the opposite: fail the tool call fast, let the agent mint a link via mcporter auth <name> --no-browser --json, and present it in chat where the user can click it deliberately (the flow #169 added — thank you for that one).

#169's --no-browser / MCPORTER_OAUTH_NO_BROWSER solved this for auth and config login, but the env var is parsed only in the auth command's argv handling. Setting it on the serve process does nothing.

Current behavior (0.12.4 and 0.13.0)

• PersistentOAuthClientProvider.redirectToAuthorization (src/oauth.ts) calls openExternal(...) unless options.suppressBrowserLaunch is set — and the only caller that sets it is the auth command with --no-browser.
• On the serve/daemon path there is no way to reach that option, so every 401 → browser launch.

It also compounds into a tab loop when auth keeps failing:

• connectWithAuth makes up to 3 attempts (maxAttempts = 3), each re-entering interactive authorization;
• a pending authorization older than INTERACTIVE_AUTHORIZATION_TTL_MS (5 min) is treated as abandoned, so the next request prompts again;
• the duplicate-prompt guard from Serialize interactive OAuth authorization per shared provider/session #247 is per provider instance, and with one daemon per config hash (several repos/worktrees) each daemon prompts independently.

A persistently failing server (e.g. an IdP rejecting the client) produces an endless stream of context-free browser tabs.

Proposed fix

Honor browser suppression on the runtime/serve path. Smallest version:

1. Read MCPORTER_OAUTH_NO_BROWSER (same semantics as Add a flag to suppress browser launch in auth / config login for headless workflows #169) when constructing the OAuth session in the runtime, and pass suppressBrowserLaunch: true through to PersistentOAuthClientProvider.
2. When suppressed, fail the pending authorization promptly (or honor a short MCPORTER_OAUTH_TIMEOUT_MS as today) with an error that includes the server name, so the caller/agent can surface its own auth flow.

A per-server config field ("browser": false) or a serve --no-browser flag would also work; the env var is the minimal, consistent-with-#169 option.

Workaround we use today

A PATH shim replacing open for the bridge process tree (logs the URL instead of launching), plus MCPORTER_OAUTH_TIMEOUT_MS=20000 so the suppressed flow fails fast — works, but it depends on openExternal spawning a PATH-resolved open, which is an implementation detail we'd rather not lean on.

Happy to send a PR for option 1.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 8, 2026, 5:26 PM ET / 21:26 UTC.

Summary
Keep open: current main still limits browser suppression to the auth command, while the explicitly linked open PR owns the focused runtime repair.

Reproducibility: yes. —current source provides a high-confidence path: set MCPORTER_OAUTH_NO_BROWSER on a serve or daemon process, trigger an OAuth 401, and the runtime reaches openExternal because it never parses that environment variable.

Root-cause cluster
Relationship: canonical
Canonical: #283
Summary: This issue is the canonical report; one open PR is the explicitly linked candidate fix.

Members:

• fixed_by_candidate: fix(oauth): honor MCPORTER_OAUTH_NO_BROWSER outside the auth command #284 - The open PR explicitly targets this issue’s runtime browser-suppression gap.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Next step
A formally linked open PR already owns the bounded implementation, so another repair branch would duplicate active work.

Review details

Best possible solution:

Land a reviewed version of #284 so runtime OAuth uses the existing environment convention and returns an actionable server-specific failure when no interactive callback is available.

Do we have a high-confidence way to reproduce the issue?

Yes—current source provides a high-confidence path: set MCPORTER_OAUTH_NO_BROWSER on a serve or daemon process, trigger an OAuth 401, and the runtime reaches openExternal because it never parses that environment variable.

Is this the best way to solve the issue?

Yes—the linked PR’s provider-level fallback reuses the existing environment semantics and is narrower than adding a parallel serve-only flag or configuration field.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Until the linked repair lands, a runtime OAuth 401 can still steal focus by launching a browser in headless agent workflows.

Codex review notes: model internal, reasoning high; reviewed against c2747e2570c4.

Label changes

Label changes:

• remove clawsweeper:no-new-fix-pr: Current issue advisory state no longer selects this label.
• remove clawsweeper:linked-pr-open: Current issue advisory state no longer selects this label.

Label justifications:

• P2: This is a bounded OAuth workflow failure that disrupts daemon and agent use without indicating a security bypass or outage.
• impact:auth-provider: The affected behavior is OAuth authorization initiation and browser-launch handling.

Evidence reviewed

What I checked:

• Current runtime still opens the browser: The OAuth provider only suppresses launch when an explicit session option is set; otherwise it calls the system browser opener. Current main contains this behavior. (src/oauth.ts:343, c2747e2570c4)
• Environment variable is scoped to auth-command parsing: MCPORTER_OAUTH_NO_BROWSER is parsed in the auth command and that command alone supplies suppressBrowserLaunch to runtime.listTools; the generic HTTP runtime creates OAuth sessions from optional caller-provided options. (src/cli/auth-command.ts:195, c2747e2570c4)
• History and release provenance: Blame ties the active OAuth branch to the v0.13.0 history boundary, and current main retains it; the requested runtime behavior is therefore neither shipped in v0.13.0 nor implemented on main. (src/oauth.ts:343, 49dcd3e7fffd)
• Open implementation candidate: The provided GitHub context shows fix(oauth): honor MCPORTER_OAUTH_NO_BROWSER outside the auth command #284 is open, explicitly targets this issue, and carries after-fix daemon proof; it is the active focused repair. (fbc594d48b21)

Likely related people:

• Peter Steinberger: Current blame attributes both the OAuth launch branch and the auth-command environment parsing to this release-history boundary. (role: current OAuth implementation contributor; confidence: medium; commits: 49dcd3e7fffd; files: src/oauth.ts, src/cli/auth-command.ts, src/runtime/http-transport.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.