fix(antigravity): stop the OAuth client scan from eating a neighbouring string

[Nanako0129]

Problem

With Antigravity installed but not running, the Antigravity card shows Antigravity OAuth client was not found. Install Antigravity.app or configure its OAuth client. — even though the app is installed and the OAuth client id/secret are present in its language_server binary.

The OAuth route does not need the IDE process: discover_client_from_app reads the .app artifacts from disk with std::fs::read. So a closed-but-installed IDE should resolve a client and fetch quota. It did not, and the cause is in our scan, not in the environment.

Root cause

scan_client_ids finds the .apps.googleusercontent.com suffix, then walks backward over token bytes ([A-Za-z0-9_-]) to locate the start of the id. In the shipped language_server (a ~139 MB packed Mach-O), the bytes immediately in front of a client id belong to whatever string was laid down next to it, with no separator. The walk-back absorbs that neighbour's tail into the id's head.

A Google client id is <digits>-<token>, and valid_client_id requires the head before the first - to be all digits. With a neighbour's tail glued on, the head contains letters, so every id is rejected and the scan returns an empty vector — while scan_client_secrets, which reads a fixed-length window forward from its GOCSPX- prefix, is unaffected.

Measured on a real install (/Applications/Antigravity.app/.../bin/language_server): both client ids present in the binary were rejected, scan_client_ids returned 0, and resolve_oauth_client returned None — taking the entire OAuth route down whenever the IDE was not running.

The existing unit test did not catch this because its fixture separates the id with a \x00 byte. NUL is not a token byte, so the walk-back stops on its own — the fixture's anchor made the defect unreachable.

Fix

After the greedy walk-back, re-anchor on the first - in the candidate and keep only the digit run immediately before it. This trims any non-digit neighbour bytes back off the numeric head without disturbing the id itself.

if let Some(dash) = data[start..end].iter().position(|b| *b == b'-') {
    let mut head = start + dash;
    while head > start && data[head - 1].is_ascii_digit() {
        head -= 1;
    }
    start = head;
}

Known ceiling, recorded in the test: if a neighbour's own tail is digits, it is indistinguishable from the id's numeric head and those digits are kept. Nothing in the byte stream marks the boundary. The only stronger fix is parsing Mach-O string sections instead of scanning bytes, which is disproportionate for a case that Google's 12-digit ids make rare.

Validation

Check	Result
cargo test -p tb_core_ffi agent_antigravity	27 passed
New regression test scans_client_id_glued_to_a_neighbouring_string	passes; fails with left: [] when the fix is reverted (mutation-checked), matching the real-world ids=0
cargo clippy -p tb_core_ffi --all-targets	27 warnings before and after — none new
Real install, IDE closed, swift run TokenBar --smoke	error string moves from OAuth client was not found to token refresh was rejected — i.e. the client now resolves and the route reaches the credential stage

The remaining token refresh was rejected on that machine is a stale ~/.gemini/oauth_creds.json (expired refresh token), which is outside this change: it confirms discovery now succeeds and hands off to the refresh step correctly.

Scope

Discovery only. This is independent of #236 (which adds an agy CLI fallback for the not-installed case); it fixes the installed-but-closed case that should already work. No behaviour change for users whose IDE is running — that path never calls this scan.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ceb2195799

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".