[azrosen92]

Summary

• Adds an X-Gusto-CLI-Command: <slug> header to CLI API requests so request traffic can be grouped by command.
• Threads the dispatched command through GlobalFlags without widening every API helper signature.
• Honors the GUSTO_TELEMETRY opt-out across regular API traffic and OAuth registration, code exchange, token refresh, and token inspection requests.

Linked issue

No public issue.

Test plan

• env NO_COLOR= bun run test:all passes locally
• bun run typecheck passes locally
• bun run lint passes locally
• bun run format:check passes locally
• Header propagation, telemetry opt-out, OAuth request attribution, MCP attribution, and near-expiry session refresh have regression coverage

DCO

• Every commit is signed off (git commit -s) per the DCO

[tmfahey]

Threading it through GlobalFlags is the right call. buildApiClient is only reached via resolveApiContext and the fetch*/create*/put* helpers, all of which take just globals, so the alternative means widening every one of them to carry a string. Slug derivation, the per-attempt header build, and the copy-not-mutate in the runner all check out, and I couldn't get an argument or UUID into the slug from any command literal.

Two things I'd settle before this merges: whether GUSTO_TELEMETRY=0 should suppress this header the way it suppresses the install id, and the doc comment claiming OAuth login has no command context - it does. Both inline, along with some smaller test and doc notes.

Separately, and not about the code: the description carries an internal ticket key, and so does the branch name. CLAUDE.md:71 asks to keep those out of anything public. The description is the part that's still editable.

[tmfahey]

Nice threading - putting command on a fresh globals copy in the runner keeps every handler and helper signature untouched, and both new ApiClient sites pick it up.

One gap worth closing before merge: command rides on OAuthHttpOptions but only the bearer client reads it, so the raw /v1/mcp/oauth/token POSTs - including every session refresh a REST command triggers - still go out unattributed. Details inline, plus one test-placement nit.

[tmfahey]

Two notes that are more about the write-up than the code.

The summary's third bullet now undersells the change. It says the OAuth login token_info request gets attributed, but 4c3336e pushed the header into withInstallIdHeader, so the DCR register, the code exchange, and every mid-command token refresh carry it too. The refresh case is the one that'll dominate the volume, and it's worth having in the body so a reader can size the change from the description.

Second, GUSTO_TELEMETRY still doesn't appear in any markdown in the repo - not README, not ARCHITECTURE, not --help. fe484eb deferred that to a follow-up when the install id shipped, which was a fair call for an opaque UUID. A command name is a more legible signal than a UUID, so this feels like the change that should carry the README section, or at least land behind the follow-up rather than ahead of it.

Otherwise the threading looks right: the runner is the single injection point, every Gusto-API-bound client picks the slug up from there, and the non-runner surfaces (auto-update, upgrade) make no Gusto API calls, so there's no unattributed traffic left over.

[tmfahey]

LGTM