fix: refresh CLI credentials before each invocation

[EhabY]

• Refresh the credential file (or keyring on supported systems) before each CLI call by awaiting cliManager.configure inside commands.ts:resolveCliEnv. The CLI reads the fresh token via the existing --global-config / --url flags. mTLS still works since the refresh accepts an empty token.
• Stop wrapping AbortError inside cliError. Previously, wrapping replaced the AbortError name with stale CLI stderr, so cancellations from speedtest and support bundle looked like real failures to withCancellableProgress.
• Tighten isAbortError to narrow to Error so callers can return the error directly.
• Drop the unused keyringOnly option from storeToken.
• Add writeStdoutJs / writeStderrJs test helpers that wrap fs.writeSync. Fixes a flaky version-fallback test caused by lost async pipe writes on exit (see https://nodejs.org/api/process.html#a-note-on-process-io).

[EhabY]

/coder-agents-review

[coder-agents-review]

Three P3s, two nits. No blockers.

The env forwarding is sibling-complete: all four cliExec.ts call sites get the same buildChildEnv treatment. The mTLS empty-token edge case has its own test. The AbortError analysis is grounded in code structure (traced isExecFileException matching AbortError.code), not asserted from intuition. The isAbortError type narrowing from boolean to error is Error is a prerequisite for the cliError return, not scope drift. Commit hygiene is solid: functional change and reformat are separate commits.

"I tried four different framings of the problem and the author's framing survived all of them." (Pariston)

The main gap is that the AbortError fix (the PR's second bullet) ships without a test proving it works. The createTerminal env semantics mismatch is a real bug in one of the four call sites. And runCliCommand in workspace.ts is a sibling CLI spawn site that the PR's "every" claim misses.

PS. The reformat commit subject (reformat cliExec) doesn't follow the project's type(scope): message format; should be refactor: reformat cliExec or similar.

---

src/core/cliExec.ts:238

Nit [DEREM-2] banner is now required (string[], line 192), so if (options.banner) always evaluates to true (even an empty array is truthy). The guard can be removed, keeping only the loop body. (Netero)

🤖

src/api/workspace.ts:70

P3 [DEREM-4] runCliCommand spawns coder start/coder update via spawn(cmd, { shell: true }) with no env override. Same class of CLI child process as the four fixed in cliExec.ts.

"CliContext at workspace.ts:48 is a sibling of CliEnv at cliExec.ts:14. Both wrap 'how to invoke the coder binary.' The PR adds authEnv and buildChildEnv to CliEnv, but runCliCommand uses CliContext which has no authEnv field." (Robin)

The CLI flags still carry auth for the direct binary, so nothing breaks today. The gap matters for nested subprocesses that coder start/coder update might spawn. The PR description says "every coder CLI child process"; these two are not covered. (Kite P3, Robin P3, Hisoka P4)

🤖

🤖 This review was automatically generated with Coder Agents.

[EhabY]

DEREM-2: Done in 357814b.

DEREM-4: Skipping. The direct binary already has auth via flags, and coder start/coder update are short-lived calls we have no evidence spawn auth-needing children. Capturing {url, token} here would also break the refresh-resilience cliAuth has by design (it never carries a token). Scoped the PR description to the four cliExec.ts call sites.