mcpdo: a sign-in helper failure without a TTY loses its exit-code classification (fetch_refused reported as auth_required) #2962

Found in the v2.15.0 release smoke (#2960). It is a follow-up to #2842 / PR #2940, which classified CLI failures by exit code but only covered the front-end path.

Problem

When mcpdo connect runs without a TTY, OAuth sign-in runs in the detached sign-in helper. Any failure the helper reports before it produces the authorization URL is turned into auth_required / exit 3 by fail() in clients/mcpdo/src/connection/auth-helper.ts. That happens even when the front-end path classifies the same failure more specifically.

The case observed in the smoke was a fetch-guard refusal. The same server gives different results depending on the path:

The url field is lost as well.

Reproduce

1. Run an OAuth composable test server with "mode":"protected-resource","authorizationServers":["http://169.254.169.254"] on a local port.
2. HOME=<fresh> mcpdo --format json connect http://127.0.0.1:<port>/mcp </dev/null; echo $?
3. The output is auth_required / 3. The expected output is fetch_refused / 12, the same as the TTY path.

Who hits it

The path is common, but the trigger is narrow. Running without a TTY is how agents drive mcpdo (see skills/mcpdo). The issue only fires on a failure before the authorization URL exists:

• a fetch-guard refusal
• a discovery failure
• a client-registration error

A user declining consent happens after the URL exists, so it is not affected. The message still names the cause, and exit 3 still reads as an auth problem, so only a caller that distinguishes 12 from 3 misroutes.

Expected

The helper relays enough of the original error, such as a code and a url, for the parent to raise the same classified CliExitCodeError the TTY path does. auth_required should be the fallback only for failures that have no classification.