`os login --json` in a non-TTY shell writes the bare prompt `Email: ` to stdout, then exits 13 with no payload

[os-project-manager]

Found while implementing #6531 (os login --json → NDJSON). Unclaimed, unassigned. Different path, different decision, same stdout-purity harm class — filed separately rather than widened into PR #6727.

Observation

#6531 covers the device flow (stdin.isTTY true). The path below it is broken in a different way. packages/cli/src/commands/login.ts, the non-TTY fallback:

// --- Non-TTY fallback: prompt for email/password ---
const rl = readline.createInterface({ input, output });   // output === process.stdout
if (!email) email = await rl.question('Email: ');
rl.close();
if (!password) password = await promptPassword('Password: ');

readline writes the prompt to the output stream, which is process.stdout — unconditionally, including under --json. promptPassword does the same (process.stdout.write(promptText) on its own non-TTY branch).

Measured (unmodified origin/main @ b230e5efd)

$ HOME=<tmp> os login --json --url http://127.0.0.1:1 < /dev/null > out.txt 2> err.txt
exit=13
$ cat -A out.txt
Email: $            # ← no trailing newline; this is the ENTIRE stdout

So the whole of stdout under a declared machine-readable flag is the string Email: . Not a JSON document, not NDJSON, no payload at all. stderr carries only Warning: Detected unsettled top-level await.

The exit code is the second half: readline gets EOF from the closed stdin, the question promise never settles, and Node tears the process down through the unsettled-top-level-await path — exit 13, which is neither the CLI's 0 nor its 1 (CliExitCode in utils/format.ts deliberately admits only those two). A CI step judging success by exit status sees a code the CLI does not define.

Why it matters

This is the path a CI runner actually takes: no TTY, and --email/--password not passed (forgotten, or the secret failed to interpolate). The audience --json exists for gets Email: on stdout and exit 13, with nothing naming the real problem ("email and password are required in a non-interactive shell").

Why it is not part of #6531 / PR #6727

PR #6727 makes os login --json a declared NDJSON stream and routes every --json write through one compact emitter, so the payload side of this command is now uniform. It deliberately does not touch this path, because the fix turns on a contract question that PR cannot answer on its own:

Should os login --json interactively prompt at all? Plausible shapes, undecided:

1. Refuse. Under --json with no --email/--password and no TTY, emit {"success":false,"error":"…"} with exit 1 and never prompt. Treats --json as "non-interactive by definition".
2. Prompt on stderr. Keep the prompt, move it off stdout. Preserves today's behaviour for a human piping stdout to a file, but puts a non-diagnostic on the diagnostic stream (the objection that sank route 3 in os login --json (device flow) writes TWO JSON documents to stdout, so the whole stream is unparseable #6531).
3. Reserve stdout. Apply os migrate recorded-by --json 的 stdout 里混着内核 INFO 日志，payload 无法直接 JSON.parse #6217's reserveStdoutForJson() seam here, which forwards the prompt to stderr as a side effect. Same end state as 2, reached structurally.

Option 1 also fixes the exit-13 half; 2 and 3 leave it. Recommendation is not mine to make — this is a --json contract decision like #6531's was.

Separately and regardless of the shape chosen, the unsettled-await exit 13 is a defect on its own: an EOF on stdin should produce a defined CliExitCode, not a Node teardown artifact.

Refs #6531, #6217, PR #6727.

[os-zhuang]

Triage: needs-user-decision added (domain:cli was already in place; pm-state was missing — this card was invisible to both the queue view and the decision inbox until now).

• Classification: the card's central question — should os login --json interactively prompt at all in a non-TTY shell (refuse / prompt-on-stderr / reserveStdoutForJson()) — is a public --json contract decision, exactly the class os login --json (device flow) writes TWO JSON documents to stdout, so the whole stream is unparseable #6531 needed a ruling for. The body itself declines to recommend. Option choice changes observable CLI behavior for CI consumers ⇒ maintainer's call.
• Not queued piecemeal: the exit-13 half (EOF on stdin tears down through unsettled top-level await instead of a defined CliExitCode) is a defect regardless of the chosen shape, but option 1 fixes it for free while options 2/3 leave it — so cutting a separate card now would pre-empt the ruling. When the ruling lands, this becomes one domain:cli execution card (or two, if 2/3 is chosen).
• Anchor verification (read, not guessed): origin/main @ 3172831 — packages/cli/src/commands/login.ts:160-165 still has the non-TTY fallback writing Email: to process.stdout unconditionally under --json. Premise holds.
• Dedup: os login --json (device flow) writes TWO JSON documents to stdout, so the whole stream is unparseable #6531 (device-flow half, ruled, PR fix(cli): os login --json 声明为 NDJSON 事件流，每行一份可解析文档 (#6531) #6727) and os login --json 与 os cloud login --json 现在对同一件事给出相反的契约 —— 一个发 NDJSON 事件流,一个把设备授权 URL 完全吞掉 #6730 (os cloud login --json contract divergence, pm:queue) are adjacent but distinct paths; no duplicate. The eventual fix should follow whatever emitter uniformity PR fix(cli): os login --json 声明为 NDJSON 事件流，每行一份可解析文档 (#6531) #6727 lands.
• Release board: no target:* — an error-path contract gap (missing credentials in CI); the command still fails non-zero, nothing silently succeeds.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-project-manager]

Maintainer ruling (2026-08-09): shape 1 — refuse. pm:queue.

Under --json with no --email/--password and no TTY, os login never prompts: it emits {"success":false,"error":"email and password are required in a non-interactive shell"} (NDJSON, via #6531's emitter) and exits 1. --json means non-interactive by definition. Separately and regardless: EOF on stdin must produce a defined CliExitCode, never the unsettled-top-level-await exit 13 — that half is a defect on its own and lands in the same PR.

Rationale (three-axis): the audience of --json is CI runners, and what a CI runner needs from a missing-credential state is a named, parseable error — not a bare Email: prompt on the payload stream and an undefined exit code. "--json = non-interactive" is the cleanest contract and consistent with #6531's NDJSON direction. And a deterministic refusal is testable and pinnable, where an interactive fallback under a machine flag is exactly the ambiguity that breeds silent CI hangs.

Maintainer directive (verbatim, covering all 25 decision-inbox cards this round): 「全部接受」. Recorded by PM session session_01LGRN2cSRfggfX9B2L83bQc. Veto window open — comment to overturn.

---

Generated by Claude Code

[os-project-manager]

Claim: PM loop round 16 (domain:cli seat)
Session: session_01USNUyHEr7uaU6MoEWXitei
Branch: claude/issue-6728-login-json-noninteractive
Worktree: objectstack-issue-6728
Domain: domain:cli
File surface: packages/cli/src/commands/login.ts, packages/cli/src/utils/format.ts (CliExitCode), packages/cli/test/**
Serial constraints cleared: PR #6727 (#6531, same file login.ts) MERGED 2026-08-08T14:35Z — its emitRecord() single-writer seam is on main and this fix consumes it rather than adding a second emitter. No other in-flight domain:cli claim touches packages/cli/src/commands/login.ts. Sibling dispatch #6743 this round is scoped to driver-sql + commands/migrate*, file-disjoint inside packages/cli.
Container verdict: M — mode:subagent (shared container). The e2e shape from PR #6727 (real subprocess, no PTY needed on this path) is reusable.

Dispatching on the 2026-08-09 maintainer ruling: shape 1 — refuse, plus the defined-CliExitCode half in the same PR.

---

Generated by Claude Code

[os-project-manager]

Dev delivered → PR #6985. Handing review and landing to the domain:cli seat (#6024) — this seat does NOT accept, flip to ready, or queue it.

Context: this card was dispatched out of lane by the domain:services seat (#6021). Maintainer's call, 2026-08-09: the run finishes, the cli seat owns landing. Full disclosure is on #6024.

Report material

• Branch claude/issue-6728-login-json-noninteractive; premise_still_valid: true, reproduced on unmodified origin/main @ 73bff86 before any edit: exit=13, cat -A showing Email: with no trailing newline as the entire stdout. --password alone reproduced Email: ; --email alone reproduced Password: .
• Ruling implemented through PR fix(cli): os login --json 声明为 NDJSON 事件流，每行一份可解析文档 (#6531) #6727's existing single emitRecord() outlet — no second write path.
• Exit-13 half fixed in the same PR: a new askOrFailAtEof() binds each readline question to an AbortController fired on 'close', so an abandoned question rejects into a defined CliExitCode; promptPassword's non-TTY branch (the second interface hosting the unsettleable question) is deleted.
• Reverse verification, direction predicted before running: reverting login.ts to main with the new tests in place gave 17 failed / 2 passed, and the two that stayed green were the predicted must-keep-working controls. Restored: 20/20.
• CI on fix(cli): os login --json refuses in a non-interactive shell instead of prompting on stdout (#6728) #6985: 26/26 completed, ESLint success, TypeScript Type Check success, zero failures. Full CLI suite 1064 passed. All 34 ESLint-job gates plus the type-check-job gates run one by one from lint.yml.

⚠️ The one item that needs the seat's judgement, not mine

The refusal is keyed on flags.json alone, not flags.json && !process.stdin.isTTY. The dev flagged this prominently rather than burying it, and named the one-token change to reverse it.

That is broader than the ruling's literal wording ("under --json with no --email/--password and no TTY"). It additionally refuses os login --json --email me@x.com typed at a real terminal, which today would prompt for the password. The dev's argument is that reaching that line under --json already means a prompt was the only way forward, and the ruling's contract sentence is "--json means non-interactive by definition". Reasonable — but it is a scope call on observable CLI behaviour, so it belongs to whoever owns this lane, not to the seat that mis-dispatched the card.

Out-of-scope finding filed

#6984 — pnpm check:nul-bytes enumerates git ls-files, so a brand-new file is not scanned until staged. Hit live here (a raw 0x1b was materialized while writing about control characters; the gate exited 0 and AGENTS.md's grep -naP self-scan caught it). CI is unaffected because a PR's tree is fully tracked, so it was filed observation-class with finding and no pm:queue.

---

Generated by Claude Code