[l2ysho]

One item off the "Not in this PR" list of #1402:

apify mcp install embeds the resolved token in the client config; with an OAuth login that token dies after an hour, so it should warn or ask for --token.

apify mcp install copies the resolved API token into the MCP client's config file. Nothing refreshes that copy, so since OAuth became the apify login default, the configured server stops working within the hour and the user has no idea why.

What changed

When the resolved token belongs to an oauth2 profile with under a day of life left, the command now:

• warns with the remaining lifetime and points at --token with a long-lived Console token. The link is account-scoped through getConsoleIntegrationsUrl(), so an organization login lands on its own /organization/<id> route;
• asks before writing in a terminal, default No;
• exits InvalidInput with the same explanation when there's no terminal to ask on;
• writes without asking under --yes, warning first. --yes is handled before the prompt rather than through preAnswered, so the warning still prints.

--token, APIFY_TOKEN, plain API-token logins and the tokenless codex client all skip the check.

Release note: the non-interactive abort and exit code 5 are new. Nothing released produces an oauth2 profile yet (#1402 landed after 1.10.0), and both scripted paths that exist today are immune — APIFY_TOKEN resolves with source: 'env' and no profile, --token skips resolveAuth entirely — so this shouldn't break anyone, but it's a new failure mode.

Two fixes it dragged in

--yes was ignored on a TTY. stdinCheckWrapper only read the fallback answer when stdin couldn't be prompted, so --yes was dropped in a terminal, contradicting YesFlag's own Answer "yes" to all prompts. The overwrite prompt has always had this, but it only fires on re-install; the new prompt fires on every OAuth-login install, which made it a hang rather than a wart. Added a preAnswered option and moved every --yes call site onto it: actors rm, datasets rm, runs rm, key-value-stores rm, key-value-stores delete-value, builds rm, builds remove-tag, both mcp install prompts. That left providedConfirmFromStdin with one caller passing a literal false, which was never an answer from stdin, so it's now defaultWhenNonInteractive.

Splitting the seven rm commands into their own PR would leave two contradictory --yes semantics across a release, which is why they're here.

The prompt could hang outside CI. useStdin sets hasData for any stdin that isn't a terminal, /dev/null and a closed descriptor included, so the hook's non-interactive branch never fired outside CI. A Docker build or cron job would have hung where it used to succeed. The expiry confirmation checks for a terminal itself now.

Follow-ups

• useStdin.hasData is the root of that hang, and it's latent in every other useYesNoConfirm caller. The !stdinStream.isTTY || disjunct means !isTTY implies hasData, so !isTTY && !hasData is only reachable after readStdin() drains stdin. Dropping that disjunct fixes it for everyone; echo y | apify actors rm X keeps working and < /dev/null fails with the hint instead of hanging. Two consumers. Deliberately not done here — create.ts:287 already carries the same command-local workaround, so this PR is the third instance and the convention is wrong.
• The expiry derivation now exists three times: auth/token.ts, run.ts, and mcp/install.ts, each with its own wording. The differing thresholds are correct (durability differs), the differing wording isn't. Adding expiresAt to ResolvedAuth and exporting describeExpiry() collapses all three.
• run.ts still has the "0 minutes" bug this PR fixed in its own copy: Math.max(0, Math.round(remainingMs / 60_000)) reports a token with 30 seconds left as "expires in about 0 minutes". Folds into the above for free.
• apify auth list still doesn't show how an account logged in or when its session expires (also from feat: log in through OAuth 2.0 device code by default #1402).

Numbers

No dependency changes, so no install-size impact. 16 new tests: test/local/commands/mcp/install.test.ts, a new install-non-tty.test.ts that leaves isCI false (the case that hung), and test/local/lib/hooks/stdin-check-wrapper.test.ts. docs/reference.md regenerated. test:api not run, nothing here touches the Apify API. The 17 failures in test:local are identical on master (python/git/npm fixtures).

---

Generated by Claude Code

[apify-factory]

Looks good, nothing blocking.

🏭 Factory review — ℹ️ not auto-approved

This change was reviewed but cannot be auto-approved: a gate failed, so the review cannot end in an approval.

check	result
Static gates	❌ 13/16 — pr-open-and-ready, max-files, max-lines
Review findings	✅ none
Reviewer escalation	❌ Changes how auth tokens are handled and adds a new non-interactive failure (exit code 5), and it changes --yes across seven destructive rm/delete commands so they no longer prompt on a TTY, which is a public CLI contract change beyond what the title says.
Juror 1 — claude-sonnet-5-5, adversarial	⏭️ skipped — a gate failed

Why it was not auto-approved

Failed gates:

• pr-open-and-ready: PR is a draft
• max-files: 15 changed files, limit 10
• max-lines: 430 changed lines (+402/-28), limit 200

The comments above are the review itself; this section only explains the approval decision. Push a change and request @apify-factory again to re-run it, or ask a human to review.

_{Reviewed 91a1dde4b · workflow run}

[DaveHanns]

The idea makes sense. Code reviewed partially. The Apify factory review to be taken into account.

[szaganek]

Suggested change

	description: `Apify API token to embed in the config. Defaults to APIFY_TOKEN, then the token from 'apify login'. A token from an OAuth 'apify login' expires after about an hour, so pass a long-lived one from Apify Console.`,
	description: `Apify API token to embed in the config. Defaults to APIFY_TOKEN, then the token from 'apify login'. A token from an OAuth 'apify login' expires after about an hour, so pass a personal one from Apify Console.`,

Long-lived sounds wonky