Repository navigation
Conversation
…g SSH hosts Antigravity usage was a relabelled copy of the Gemini Code Assist read, so it showed the wrong pools and went unavailable whenever no Gemini CLI sign-in existed. This adds a real read: the Antigravity CLI's own OAuth credential, the Antigravity `ideType`, and `retrieveUserQuotaSummary`. The credential is looked up on this machine first and then on connected SSH targets, so a dev box where `agy` runs but no Antigravity process is reachable from this machine now reports its quota. The Gemini mirror stays as the fallback whenever no direct read succeeds. Two details the endpoint requires that are easy to miss: - cloudcode-pa selects the product from the User-Agent, not from the request body. Without "antigravity" in it, `loadCodeAssist` still answers 200 but omits `cloudaicompanionProject`, and the quota call then fails 403 — which reads as a bad sign-in. Electron's default Chromium User-Agent resolves to a different product with no quota grant. - the response is grouped, and two groups routinely report identical percentages and reset times, so buckets stay keyed by group rather than being deduplicated. A remote host that drops mid-read is reported as unchecked rather than as a missing sign-in; a target that was never connected is not treated as evidence either way.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (4)
Included review availability: Your plan provides up to 10 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughAdds Antigravity OAuth credential parsing and discovery across local and SSH hosts. Adds a Cloud Code quota client with project resolution, quota retrieval, response validation, host fallback, timeout, and cancellation. Converts quota groups into session and weekly rate-limit windows. Integrates Antigravity fetching into refresh cycles and uses Gemini-derived limits when direct results are unavailable. Updates status-bar visibility using PATH detection or Antigravity quota snapshots. Adds coverage for credentials, API behavior, quota conversion, provider outcomes, service integration, and status-bar behavior. Merge Risk: ⚪ Minimal · up to Antigravity usage can now be configured and displayed independently of Gemini CLI OAuth, including remotely sourced quota states. No current merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Team
Run ID: 24644483-5e13-43c8-9cc3-aa183a15e85c
📒 Files selected for processing (20)
src/main/rate-limits/antigravity-cloud-code-api.test.tssrc/main/rate-limits/antigravity-cloud-code-api.tssrc/main/rate-limits/antigravity-credential-hosts.test.tssrc/main/rate-limits/antigravity-credential-hosts.tssrc/main/rate-limits/antigravity-oauth-credential.test.tssrc/main/rate-limits/antigravity-oauth-credential.tssrc/main/rate-limits/antigravity-quota-buckets.test.tssrc/main/rate-limits/antigravity-quota-buckets.tssrc/main/rate-limits/antigravity-quota-fetch.test.tssrc/main/rate-limits/antigravity-quota-fetch.tssrc/main/rate-limits/rate-limit-service-test-harness.tssrc/main/rate-limits/service-account-target-selection.test.tssrc/main/rate-limits/service-antigravity-usage.test.tssrc/main/rate-limits/service-inactive-account-previews.test.tssrc/main/rate-limits/service-live-claude-usage.test.tssrc/main/rate-limits/service-minimax-usage.test.tssrc/main/rate-limits/service-refresh-orchestration.test.tssrc/main/rate-limits/service-window-activation.test.tssrc/main/rate-limits/service/service-full-cycle-application.tssrc/main/rate-limits/service/service-full-cycle-preparation.ts
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review.
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
There was a problem hiding this comment.
Important
The data path is sound and well-tested, but the renderer still hides the Antigravity bar in exactly the scenario this PR targets (a host where only agy exists) — see the first section below.
Reviewed changes
- Credential parsing (
antigravity-oauth-credential.ts) — parses theagyOAuth blob in both plain-JSON andgo-keyring-base64:encodings, with NaN-safe expiry handling. - Cross-host credential lookup (
antigravity-credential-hosts.ts) — local first, then connected SSH targets viaresolveFilesystemRouteForHost, mapping transport failures to theunverifiableverdict and skipping unconnected/idle targets. - Two-step Cloud Code call (
antigravity-cloud-code-api.ts) —loadCodeAssist+retrieveUserQuotaSummaryagainst the daily/stable hosts, with the Antigravity User-Agent and daily→stable fallback. - Bucket mapping (
antigravity-quota-buckets.ts) — group-keyed buckets,window→windowMinutes, and per-window "most constrained" summary. - Service integration — a 7th
Promise.allSettledprovider; the Gemini mirror remains the fallback whenever the direct read is notok.
⚠️ Status-bar visibility still gates Antigravity on local CLI detection and the Gemini opt-in
The PR's headline case is a dev box where agy exists only on the SSH host, with no local sign-in. But the status-bar slot is CLI-gated on local PATH detection (isStatusBarItemAvailable('antigravity', detectedAgentIds), status-bar-agent-gating.ts:15, consumed at use-status-bar-controller.ts:141), and the toggle itself is hidden by the same check (StatusBarVisibilityMenu.tsx:77). A client with no agy on its own PATH gets a detectedAgentIds that lacks antigravity, so showAntigravity is false and the bar never renders — even when the direct read succeeds. The same files still carry "the Antigravity snapshot mirrors the Gemini fetch" comments and tie the slot to geminiCliOAuthEnabled (status-bar-provider-visibility.ts:105), which are no longer accurate.
Technical details
# Antigravity bar hidden for SSH-only hosts
## Affected sites
- src/renderer/src/components/status-bar/status-bar-agent-gating.ts:15 — `'antigravity'` is in `CLI_GATED_ITEMS`; `isStatusBarItemAvailable` returns `false` unless `agy` is detected on the local PATH.
- src/renderer/src/components/status-bar/use-status-bar-controller.ts:141 — `showAntigravity` ANDs that check into visibility.
- src/renderer/src/components/status-bar/status-bar-provider-visibility.ts:105 — `hasUsageProviderSettingsForProvider` ties the durable slot to `geminiCliOAuthEnabled`; the "mirrors the Gemini fetch" comments are now stale.
- src/renderer/src/components/status-bar/StatusBarVisibilityMenu.tsx:77 — the toggle is hidden when detection misses `antigravity`.
## Required outcome
- The Antigravity bar can appear when `agy` exists only on a connected SSH host (or a credential file exists with no local CLI), i.e. a successful credential-based read must not be suppressed by the local-CLI gate. Decide whether to drop the CLI gate for Antigravity, detect it from credential presence, or explicitly document that a local `agy` remains a requirement.
- Update the now-incorrect "mirrors the Gemini fetch" comments and the `geminiCliOAuthEnabled` coupling so the durable-signal logic reflects the new direct-read source.DeepSeek Pro (free via Pullfrog for OSS) ｜ 𝕏
…g Antigravity Review follow-ups. Host fallback never worked for the failure it existed for. `fetchFromHost` did not catch a rejected request, so a network-level failure on the daily host left `fetchAntigravityQuota` before the stable host was tried, and both hosts shared one `AbortSignal.timeout`, so a slow first host handed the fallback a signal that had already fired. Each host now gets its own deadline and its own catch, and a caller abort stops the loop instead of burning a second attempt. The direct read's verdicts were unreachable. Every non-`ok` result was replaced by the Gemini mirror, so "the sign-in on <host> has expired" and "the remote host did not answer" could never be shown — including the `unverifiable` distinction this path exists to preserve. Those two verdicts now survive the fallback; no sign-in anywhere, no Antigravity grant, and transient endpoint failures still degrade to the mirror, which is the only case where it has something to say. The status bar hid Antigravity in exactly the case this targets. The slot was gated on local PATH detection, so a client with no `agy` of its own never rendered the bar even when the remote read succeeded, and the slot additionally required the Gemini CLI opt-in because the snapshot used to mirror that fetch. A snapshot carrying quota now counts as availability on its own, and the Gemini opt-in is no longer a precondition.
|
Thanks — three real findings, all confirmed and fixed in 1. Host fallback never worked for the failure it existed for (@coderabbitai)Correct, and worse than the comment says — there were two defects stacked:
Each host now gets its own deadline and its own catch, and a caller abort stops the loop rather than burning a second attempt. My original test only covered an HTTP 500 response, never a thrown one, which is why it passed; there are now tests for outright rejection, for the per-host deadline being distinct, and for the caller-abort case. 2. Direct-read verdicts were unreachable (@pullfrog)Also correct, and it made the part of this PR I argued hardest for into dead code. Answering the open question directly: the mirror should not win over a verdict about the user's own Antigravity sign-in.
3. Status bar hid Antigravity in exactly the targeted case (@pullfrog)This one would have shipped the feature with its headline case broken, and I could not have seen it locally —
Not addressed: docstring coverageLeaving this one. Verification
|
|
Softened the User-Agent claim in the description — no code change. The previous wording stated the UA behaviour as a property of the endpoint. It is one account's measurement, and I had left the most interesting row unexplained: the same token resolves to I have no second account to test that on, so the description now says so plainly, and notes that failing to reproduce the 403 is consistent with that reading rather than evidence against it. The change this PR makes is unaffected either way: pinning the UA is required in the case I can measure and harmless in the case I cannot. If a reviewer with an Antigravity-only account is willing to run |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/renderer/src/components/status-bar/status-bar-provider-visibility.ts (1)
76-80: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winInclude
antigravityUsageConfiguredin the aggregate setting check.When
antigravityUsageConfiguredis true andgeminiCliOAuthEnabledis false,hasUsageProviderSettingsreturns false. This contradicts the Antigravity-specific rule at Lines 104-106. Aggregate callers can classify a valid Antigravity setup as absent.Proposed fix
settings?.geminiCliOAuthEnabled === true || Boolean(settings?.opencodeSessionCookie?.trim()) || - // Antigravity's durable signal requires geminiCliOAuthEnabled, so it is - // already covered by the gemini term above. + settings?.antigravityUsageConfigured === true || settings?.minimaxCookieConfigured === true ||
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Team
Run ID: efd4f15e-b1aa-4efa-9211-aa56e16f5f06
📒 Files selected for processing (11)
src/main/rate-limits/antigravity-cloud-code-api.test.tssrc/main/rate-limits/antigravity-cloud-code-api.tssrc/main/rate-limits/antigravity-usage-mirror.test.tssrc/main/rate-limits/antigravity-usage-mirror.tssrc/main/rate-limits/service/service-full-cycle-application.tssrc/renderer/src/components/status-bar/StatusBarVisibilityMenu.tsxsrc/renderer/src/components/status-bar/status-bar-agent-gating.test.tssrc/renderer/src/components/status-bar/status-bar-agent-gating.tssrc/renderer/src/components/status-bar/status-bar-provider-visibility.test.tssrc/renderer/src/components/status-bar/status-bar-provider-visibility.tssrc/renderer/src/components/status-bar/use-status-bar-controller.ts
🚧 Files skipped from review as they are similar to previous changes (2)
- src/main/rate-limits/antigravity-cloud-code-api.ts
- src/main/rate-limits/antigravity-cloud-code-api.test.ts
Included review availability: Your plan provides up to 10 included reviews per hour; 8 remain after this review.
|
Tip For best results, initiate chat on the files or code changes.
The host fallback fix addresses the reported failure modes. Separate per-host timeouts and caller-abort short-circuiting are the correct behavior. The added rejection, deadline-isolation, and abort tests cover the previously missing cases. I agree that broad docstring coverage would conflict with the documented repository convention. Concise comments for non-obvious behavior are sufficient here. 🐇 ✅ ✏️ Learnings added
If you found this review helpful, would you consider giving us a shout-out on X? Thank you for using CodeRabbit! You are interacting with an AI system. |
There was a problem hiding this comment.
Important
The renderer still hides Antigravity for SSH-only hosts once the credential leaves the ok state — see the inline comment. The rest of this delta is sound.
Reviewed changes
- Surfaced terminal verdicts —
resolveAntigravityRateLimitsnow returns the direct read forstale-token/networkinstead of letting the Gemini mirror overwrite them, so an expired/rejected sign-in and a lost remote host are no longer silently republished as the shared Code Assist pool. - Per-host deadlines —
fetchAntigravityQuotabuilds a fresh timeout per Cloud Code host and catches rejected requests, so the daily host's failure no longer spends the stable host's budget. - Decoupled the slot from the local CLI and the Gemini opt-in —
isAntigravityStatusBarAvailable/antigravitySlotAvailablelet a snapshot carrying quota (or a detectedagy) keep the bar and its toggle, andhasUsageProviderSettingsForProviderdrops thegeminiCliOAuthEnabledprecondition.
ℹ️ Nitpicks
hasUsageProviderSettingsinsrc/renderer/src/components/status-bar/status-bar-provider-visibility.tsand the matching test comment instatus-bar-provider-visibility.test.tsstill say Antigravity's durable signal "requires geminiCliOAuthEnabled" — stale now that the Gemini opt-in is no longer a precondition.
DeepSeek Pro (free via Pullfrog for OSS) ｜ 𝕏
… its host drops Two fixes from the last round cancelled each other out. The direct read's `stale-token` and `network` verdicts are surfaced on purpose, but the status-bar slot was gated on `status === 'ok'`, so on a client with no local `agy` the bar disappeared the moment either verdict landed — burying the message that explains what to do about it, in exactly the case this targets. Availability is now a named credential source rather than a healthy status: it marks that a sign-in was found on some host, which is what makes the slot worth showing whatever state that sign-in is in. No sign-in anywhere still hides the bar, and the Gemini mirror names no source, so mirror-only users keep the local-CLI gate they had before. Also aligns `hasUsageProviderSettings` with the per-provider rule it had drifted from: a checked Antigravity item no longer needs the Gemini opt-in to count as configured usage, so the setup CTA does not contradict a live Antigravity bar.
|
Surfaced verdicts were re-hidden for SSH-only hosts
Answering the open question: the bar should stay visible and show the expiry message. A sign-in that exists but has expired is not the same as no sign-in, and the remedy ("run the Antigravity CLI on that host") is only reachable if the bar renders. Availability is now a named credential source rather than a healthy status: isStatusBarItemAvailable('antigravity', detectedAgentIds) ||
Boolean(antigravity?.usageMetadata?.credentialSource)
Stale aggregate ruleCaught by @coderabbitai as well, and it was a genuine contradiction rather than only a stale comment:
|
There was a problem hiding this comment.
ℹ️ All three prior findings are addressed cleanly; one rough edge remains in how the surfaced verdicts meet the status-bar gate.
Reviewed changes
- Gave each Cloud Code host its own attempt —
fetchAntigravityQuotanow builds a fresh deadline per host and catches a rejected request as that host's verdict, so the daily→stable fallback actually runs on a network failure, and a caller abort stops the loop instead of burning a second attempt. - Made the mirror fallback verdict-aware —
resolveAntigravityRateLimitssurfacesstale-tokenandnetworkverdicts and only falls back to the Gemini mirror for missing-sign-in, no-grant, and transient failures. - Stopped gating the Antigravity bar on the Gemini opt-in and local CLI —
isAntigravityStatusBarAvailabletreats anoksnapshot as availability and is threaded through the visibility toggle andshowAntigravity;hasUsageProviderSettingsForProviderdrops thegeminiCliOAuthEnabledcoupling.
DeepSeek Pro (free via Pullfrog for OSS) ｜ 𝕏
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
- Keyed Antigravity slot availability on the credential source —
isAntigravityStatusBarAvailablenow treatsusageMetadata.credentialSource(rather thanstatus === 'ok') as proof a sign-in was found, so the surfacedstale-tokenandnetworkverdicts keep the bar visible for clients without a localagy. - Made the checked item durable on its own —
hasUsageProviderSettingsnow countsantigravityUsageConfigured, matchinghasUsageProviderSettingsForProviderand dropping the stale Gemini-opt-in comment.
DeepSeek Pro (free via Pullfrog for OSS) ｜ 𝕏
|
Tip For best results, initiate chat on the files or code changes.
The The aggregate configuration rule now matches the provider-specific rule. A configured Antigravity-only user will not see an incorrect setup CTA. The focused test, type-check, and lint results support the changes. 🐇 ✅ ✏️ Learnings added
🧠 Learnings usedYou are interacting with an AI system. |
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
- Slot gating now keys on a named credential source —
isAntigravityStatusBarAvailableadmits the Antigravity slot whenusageMetadata.credentialSourceis present rather than only whenstatus === 'ok', so the surfacedstale-token/networkverdicts (and a plainok) keep the bar visible for SSH-only clients, while the Gemini mirror — which never names a source — cannot widen the slot. - Dropped the Gemini opt-in precondition for the durable signal —
hasUsageProviderSettingsForProvider('antigravity')and the aggregatehasUsageProviderSettingsnow treat a checked Antigravity item as durable on its own, and the stale "mirrors the Gemini fetch"/"requires geminiCliOAuthEnabled" comments are gone.
DeepSeek Pro (free via Pullfrog for OSS) ｜ 𝕏
|
Flagging an overlap I missed when I opened this, plus one more related issue — description updated, no code change. #8064 changes the same gate in They are not redundant. Antigravity's evidence cannot be "a successful usage fetch": the If #8064 lands first, I am happy to rebase onto its parameter and pass Also linked #18837 — usage refresh in an SSH workspace overwriting AI Agent visibility with client-side detection. The status-bar change here keeps Antigravity from being hidden by that overwrite, but only Antigravity; the runtime-host scoping @AmethystLiang describes there is the general fix, and the two are compatible. |
|
No action needed. This comment is the PR author's own note announcing a description-only update (explicitly "no code change"): it flags the textual overlap with #8064 in
|
|
Windows credential gap — acknowledged, no regression A report on #16710 notes that This PR's file-based reader will return "missing-credentials" on Windows and fall back to the Gemini mirror — identical to today's behaviour, so there is no regression. Reading from Windows Credential Manager is a possible follow-up but would expand scope here. Adding to the known limitations in the description:
Also worth noting from the same report: User-Agent made no difference on a Google AI Pro ( |
|
Review verdict: Do not merge as-is; superseded by #21654 → #21678. This PR routes quota through Antigravity credential/cloud-code endpoints, while the maintained migration uses the installed CLI contract and explicit host boundaries. SSH/remote quota remains a separate follow-up, not a reason to revive this path. |
This branch has not been deployed
2 participants
ELI5
Orca's "Antigravity" usage number was never actually Antigravity's. It was the Gemini Code Assist number with a different label glued on, so it showed the wrong pools — and if you had no Gemini CLI sign-in, it showed nothing at all. This PR makes Orca ask Antigravity directly, using the credential the Antigravity CLI writes for itself. Because that is just a file, Orca can also read it on a connected SSH host, so a remote dev box where you actually run
agyfinally reports its quota.What Changed
loadCodeAssistwithideType: "ANTIGRAVITY"→retrieveUserQuotaSummary.usageMetadata.credentialSource.Gemini Models,Claude and GPT models) and the reportedwindowmaps towindowMinutes(weekly→ 10080,5h→ 300).New files, all under
src/main/rate-limits/:antigravity-oauth-credential.tsgo-keyring-base64:)antigravity-credential-hosts.tsantigravity-cloud-code-api.tsantigravity-quota-buckets.tsRateLimitBucketantigravity-quota-fetch.tsProviderRateLimitsWhy
Two details of this endpoint are easy to miss, and I think they explain why the credential path has looked broken:
1. On this account,
cloudcode-paresolved the product from the User-Agent rather than from the request body. With a UA that does not containantigravity,loadCodeAssiststill answered HTTP 200 but omittedcloudaicompanionProject, and the quota call then failed 403 — which reads exactly like a bad sign-in.Measured against one account, same access token,
ideType: "ANTIGRAVITY"fixed:cloudaicompanionProjectretrieveUserQuotaSummaryorca/1.0/google-api-go-client/0.5standard-tierantigravityfree-tierThe discriminator was only whether the UA contains the substring
antigravity— case, position, and version format made no difference.The
standard-tierrow is the tell: the same token resolves to a different product depending on the UA. That fits an account holding both a Code Assist and an Antigravity entitlement, where the server needs the UA to disambiguate — and it predicts that an account holding only the Antigravity entitlement would succeed regardless of UA. I have not been able to test a second account, so treat this as observed here rather than proven for every account: if you cannot reproduce the failure, that is consistent with this reading rather than against it. Pinning the UA is required in the observed case and harmless in the other.Overriding the UA is already the house pattern here —
codex-backend-auth.tssendscodex-cli,claude-oauth-usage-request.tssendsclaude-code/2.1.0.2. The response is grouped, and groups collide. Two groups routinely report identical percentages and reset times, so a percentage+reset dedupe key would silently collapse a whole model family. Buckets stay keyed by group.
Linked Issue
Addresses #11409 — usage stats not refreshing on an SSH VM dev box — for the Antigravity provider. Because this path needs only a credential file, no
agyprocess has to be running or reachable from the client. Other providers remain host-local; this PR does not change them.Related: #9122 describes the mirror behaviour this replaces. The local-host path there is being handled in #11536 / #16710 via the loopback LanguageServer RPC, and this PR deliberately does not touch that path — it adds no loopback probing, no process discovery, and does not modify
antigravity-usage-fetcher.ts(which both of those PRs introduce). The two approaches are complementary: RPC whenagyis running locally, credential when it is not.Also touches #18837 — usage refresh in an SSH workspace overwriting AI Agent visibility with client-side CLI detection. The status-bar change here stops Antigravity from being hidden by that overwrite; the other providers still are, and the runtime-host scoping described in that thread is the general fix.
Overlap I should flag: #8064 changes the same gate in
status-bar-agent-gating.ts, generalising it with ahasProviderEvidenceparameter so live provider evidence outranks a stale negative detection. That is the same idea as the change here, and the two will conflict textually. They are not redundant, though: Antigravity's evidence cannot be "a successful usage fetch", because thestale-tokenandnetworkverdicts this PR deliberately surfaces are not successes and would be re-hidden by that rule. Its evidence isusageMetadata.credentialSource— a sign-in was found on some host, whatever happened next. If #8064 lands first I am happy to rebase onto its parameter and passcredentialSourceas the Antigravity evidence.Visual Proof
Same profile, same connected SSH host (
ubuntu@…, Linux,agysigned in there), no Gemini CLI sign-in on the client.Before — Antigravity is absent from the usage panel entirely; the mirror has nothing to mirror.
After — Antigravity reports its own four windows, read from the SSH host's credential.
Testing
Verified end-to-end against a real signed-in Antigravity account on a remote Linux host (Tailscale,
ubuntu@100.x), driving the production modules — not a stub:Platforms exercised: macOS client → Linux SSH host. Windows and Linux clients are unexercised; nothing in the new code is platform-specific (no shell, no child process, no path separators outside
path/path.posix).pnpm test src/main/rate-limits/→ 50 files / 520 tests pass.pnpm test(full) → 3 pre-existing environment failures unrelated to this change (claude-tui-resume-real-binary.integration,structured-agent-session-recovery-exits,agent-session-process-identity-probe); they fail identically onmainatbf4e270on this machine.oxlintclean on changed files;check:max-lines-ratchet,check:reliability-gates,check:ts-nocheck-ratchet,check:runtime-electron-ratchet,audit:code-quality:native,audit:code-quality:type-awareall pass.pnpm typecheck/pnpm lint: the only failures are the two pre-existingno-dupe-keys/ TS1117 errors insrc/main/agent-hooks/first-work-branch-rename.test.ts, present onmainand untouched here.I manually tested these changes locally
Automated tests added/updated
New tests cover: the User-Agent contract (a regression guard — the request must identify as Antigravity),
ideType, host fallback daily → stable, 401 vs 403 vs missing-project verdicts, unread-body cancellation, credential parsing in both encodings, window mapping, group-collision preservation, local-before-remote host precedence, and the unverifiable-vs-absent distinction.AI Disclosure
Claude Opus 5, used through Claude Code, for the investigation, implementation, and tests. The User-Agent behaviour in the table above was measured against the live endpoint, not inferred by the model. All findings were verified by execution.
Review
Code review summary from the agent, against the dimensions this repo asks for:
child_process, no shell, nopowershell.exe, no native module. Local reads usepath.join; remote reads usepath.posix.joinagainst a POSIX host. No new EDR-relevant surface (docs/reference/windows-edr-posture.mduntouched).resolveFilesystemRouteForHostis the only routing entry point; there is no "fall back to local" branch. A read that fails with a transport verdict (isSshRequestOutcomeUnverifiable) is reported as unchecked, never as a missing sign-in. A target the user has not connected is treated as no evidence either way rather than as an error, so an idle SSH entry cannot turn the provider red. No wire change:RateLimitRuntimeTargetis untouched, sodocs/reference/remote-wire-compatibility.mddoes not apply.Promise.allSettledcycle. Remote I/O happens only for connected targets (a disconnected one returns without touching the transport), and each remote read is bounded by the relay's own request timeout. The API call carriesAbortSignal.timeout(10s)combined with the caller's signal.agypath is read — this does not scan other applications' data directories.Agent skill upstream boundary
Notes
Known limitations, stated deliberately:
agyis in use it keeps the token current itself.agystores its token in the login keychain there, which a non-GUI SSH session cannot open. Linux and WSL hosts use a plain file and work.cloudcode-pa.googleapis.com/v1internal:*is internal and may change. Failures degrade to the existing mirror rather than to an error.Checklist
Author
X: @abruptWave