usage-limits: machine-wide `ps -ax` lifts a CSRF token from whatever Antigravity process matches first

[pitimon]

What

src/lib/usage-limits.js:1354 runs /bin/ps with ["-ax", "-o", "pid=,command="]. -a widens the
scan to every account on the machine. detectAntigravityProcess then reads the matched process's
command line and extracts --csrf_token (usage-limits.js:1365) and --extension_server_port,
returning them together with the pid.

On a shared host, the process it matches need not belong to the user running TokenTracker.

What is and is not established

• Established: the scan is machine-wide, and a CSRF token is lifted out of whatever process
  matches first. Verified on the reporting machine: /bin/ps -axo user= | sort -u lists 40 distinct
  users including a second human account.
• Established: the token is used to make an internal request
  (usage-limits.js:1593-1616 passes it as the X-Codeium-Csrf-Token header).
• NOT established: whether the token or pid reaches the GET /functions/tokentracker-usage-limits
  response. The served shape at usage-limits.js:1434 / :1486 is quota data, but not every
  getUsageLimits branch was traced. This should be settled before deciding severity.

Why it is filed separately

#129 narrowed the other ps call site — src/lib/process-list.js PS_ARGS is now -x — because
that one feeds an unauthenticated HTTP endpoint. This call site was deliberately left alone there:
nothing in that PR exercises this path, so changing it would have been an untested edit to an
unrelated feature.

Suggested work

1. Trace every getUsageLimits return branch and confirm whether csrfToken/pid can reach the
   HTTP response. That answer sets the severity.
2. Scope the scan to the current user (-x, or an explicit euid filter), or if a machine-wide scan
   is genuinely needed here, add user= to the -o spec and filter by owner in code before
   matching.
3. Add a regression test on the literal argv, as test/process-list.test.js:23 does — a real ps
   run on a single-user machine looks identical either way, so observed output cannot catch this.

Context

Found during the QA gate on #129: #129 (comment)

[pitimon]

Traced. The CSRF concern is wrong; there is a different and better one underneath it.

The open question in the issue body was whether csrfToken/pid reach the HTTP response. They do
not. But tracing that turned up an account email that does.

CSRF token and pid — cleared

All four return paths of fetchAntigravityLimits (src/lib/usage-limits.js:1795-1863):

path	returns
not configured	readAntigravityLimitsCache(...) || { configured: false }
token not found	{ configured: true, error: <literal string> }
success	finalize(...) → { configured: true, error: null, ...normalizeAntigravityResponse(payload) }
throw	{ configured: true, error: message }

processInfo.pid and processInfo.csrfToken appear only as arguments — to listAntigravityPorts,
probeAntigravityPort, and requestLocalJson (which sends the token as an
X-Codeium-Csrf-Token header, usage-limits.js:1616). Neither is ever spread into a returned
object. normalizeAntigravityResponse (:1738) builds a fixed field set from the API response
body, not from processInfo.

So the headline of this issue as filed is a false alarm. Downgrading that part.

What is actually served: account_email

normalizeAntigravityResponse returns account_email at usage-limits.js:1764
(userStatus?.email). It survives every hop to the wire:

• finalize spreads the normalize result — :1804-1810
• getUsageLimits places it at data.antigravity via withPlanLabel, which spreads {...obj} — :1885
• local-api.js:1728 serves data with json(res, data), unauthenticated

And the process whose userStatus that is comes from ps -ax (usage-limits.js:1354) — a
machine-wide scan that matches the first Antigravity process it finds, regardless of owner. On a
shared host that is another user's email address, plan name, and quota state, served to any local
process that can reach the loopback port.

The cache path carries it too (:1436, :1456), so it outlives the process it was read from.

One more, smaller

requestLocalJson throws new Error(`HTTP ${res.statusCode}: ${data}`) — usage-limits.js:1631 —
where data is the other process's raw response body. That message becomes error in the served
payload via the catch path. Not a token, but it is unbounded content from a process we do not own,
echoed to an unauthenticated endpoint.

Evidence labels — read these before acting

• Code-path verified: every hop above was read, not inferred.
• Runtime NOT verified: this machine has no Antigravity running. curl :17680/functions/tokentracker-usage-limits
  returns antigravity: {configured: false}, which is the unconfigured branch and therefore says
  nothing about the configured one. It is not evidence that the email does not appear — it is
  the absence of the precondition. Someone with Antigravity running should confirm the field is
  populated before this is treated as settled.

Suggested revision to the fix

Same as originally filed, with a different motivation: scope the scan to the current user (-x, or
an euid filter), so the process being read is one the caller already owns. Add the literal-argv
regression test — test/process-list.test.js:23 is the pattern, and it exists because a real ps
run on a single-user machine looks identical either way. Separately, consider whether the raw
upstream body belongs in a served error string at all.

[pitimon]

Step 1 settled: the token does not reach the response — what it fetches does

Traced every return branch of fetchAntigravityLimits (src/lib/usage-limits.js:1795-1863) and every read of processInfo.

The CSRF token and the pid never reach an HTTP response. processInfo is read field by field and is never spread into a returned object — pid goes to listAntigravityPorts (:1815), csrfToken becomes the X-Codeium-Csrf-Token request header (:1616, via :1818/:1833/:1848), extensionPort picks a fallback port (:1840). The four return shapes are:

branch	shape	carries token/pid?
:1798 not configured	cache, or {configured:false}	no
:1801 detection error	{configured:true, error} — error is a literal string set at :1387	no
:1837 / :1852 success	finalize(...) → {configured, error:null, ...normalizeAntigravityResponse(...)}	no
:1858 catch	{configured:true, error: message} — every throw on this path is a literal message; the token travels as a header, so it is not in any URL an error could echo	no

So this is not a token-disclosure bug. But settling that question surfaced the one that actually matters, which the issue did not ask about:

The data obtained with that token is served, and cached. normalizeAntigravityResponse (:1763-1775) returns account_email and account_plan alongside the quota windows; finalize (:1804-1812) spreads them into the result; getUsageLimits (:1976) collects it and GET /functions/tokentracker-usage-limits serves it. On a shared host, matching another account's Antigravity therefore meant displaying that person's email address, plan and quota as the local user's own.

It also persisted: writeAntigravityLimitsCache (:1470-1483) writes account_email to ~/.tokentracker/tracker/usage-limits-cache.json, and the !configured branch at :1798 keeps serving that cache after the other user's process exits.

Severity, then: not credential exposure — cross-account PII display and disk persistence, on multi-user hosts only. Single-user machines were never affected, which is also why no observed output could have caught it.

Steps 2 and 3

detectAntigravityProcess now uses the PS_BINARY / PS_ARGS already exported by src/lib/process-list.js (-x, own user) rather than its own inline -ax. Sharing the constant is deliberate: two scans that must both stay own-user should not be able to drift apart, and #129 had already fixed one of them.

Regression test scans only the current user's processes in test/usage-limits.test.js captures the literal argv from an injected commandRunner and asserts ["-x", "-o", "pid=,command="] plus the absence of any -a. Verified as a real guard, not a restatement: putting -ax back makes it fail, restoring -x makes it pass.

npm run ci:local → exit 0, 1007 CLI tests.

Worth knowing for anyone on a shared host

~/.tokentracker/tracker/usage-limits-cache.json may already hold another user's account_email from before this fix. It is a cache — deleting the file is the whole remedy, and it repopulates from your own Antigravity on the next fetch.