maintenance: recurring third-party license and distribution review #53

Activity

1. eXPerience83

   self-assigned this

   on Aug 1, 2026
2. eXPerience83 commented on Aug 1, 2026

   

   eXPerience83

   on Aug 1, 2026 – with ChatGPT Codex Connector

   OwnerAuthor

   More actions

   Initial follow-up gate completed in #54 and merged as 50d37dd31aae74d345400e7163d354cf3ff55c7b.

   The exact standalone-artifact inspection can no longer drift silently: Build AMD64 compares its five component versions, URLs and SHA-256 values against versions.env and mise.lock, with six regression tests. The next routine human review remains scheduled for 2027-02-01.
3. eXPerience83 commented on Aug 6, 2026

   

   eXPerience83

   on Aug 6, 2026 – with ChatGPT Codex Connector

   OwnerAuthor

   More actions

   2026-08-06 — out-of-cycle Antigravity runtime-admission review

   Draft PR #101 changes the availability/trust model under #96:

   • Antigravity remains unbundled and explicitly downloaded from Google's fixed official endpoint;
   • compatible official-source payloads may be admitted as Remote Dev review pending without waiting for a new image;
   • committed evidence marks reviewed versions but is not an allowlist or revocation mechanism;
   • normal startup/launch remains offline with automatic CLI updates disabled;
   • local executable/manifest integrity, origin/contract checks, private staging, unprivileged installer execution and failed-update restoration are documented and tested;
   • review-pending payloads are not claimed as signed, certified, image-SBOM content or Apache-2.0-covered.

   English and Spanish focused admission documents are included in the draft. Broad documentation synchronization remains under #92. Complete this log entry only after PR review, CI and real current-installer validation.
4. eXPerience83 commented on Aug 9, 2026

   

   eXPerience83

   on Aug 9, 2026 – with ChatGPT Codex Connector

   OwnerAuthor

   More actions

   2026-08-09 — out-of-cycle Context7 review for #94

   Reviewed the current official Context7/Upstash and OpenAI Codex documentation before implementing the Codex-only hosted MCP integration.

   Distribution / licensing boundary

   • The proposed feat: add optional Context7 integration for the Codex service #94 implementation does not bundle, download, persist or redistribute ctx7, @upstash/context7-mcp, or other Context7 executable/package bytes.
   • It configures Codex to use Context7's documented hosted Streamable HTTP MCP endpoint only after explicit user action.
   • Therefore no Context7 package license/NOTICE is added to the immutable image or build-time SBOM for this slice. Remote Dev's Apache-2.0 label continues to cover project code only.
   • Context7's open-source MCP repository is MIT-licensed, while the hosted backend/service is separately governed by Upstash's service terms.

   Current hosted-service terms/privacy reviewed

   Official Upstash legal index currently links the Context7 Addendum, Upstash Terms of Service and Upstash Privacy Policy. The Context7 Addendum (effective August 2025) expressly covers MCP integrations and grants access/use for internal development, educational and evaluation purposes. It also requires users to secure API keys, verify outputs before production use, avoid sensitive/regulated data, respect rate/access controls and comply with underlying documentation licenses.

   Current Context7 privacy/security documentation states that the original prompt/code/conversation remains with the AI assistant; Context7 receives MCP-formulated documentation search queries. Those queries may be used for server-side reranking and are anonymously stored for retrieval-quality benchmarking; API logs are documented with a 30-day retention period. Context7 states that indexed data is hosted on Upstash infrastructure in the US/EU and that the Context7 Addendum plus Upstash Terms/Privacy apply to users.

   User-facing boundary required for #94

   The implementation/documentation must therefore state clearly that:

   • Context7 is an optional external service operated by Upstash, not by Remote Dev/OpenAI;
   • enabling/testing it may send MCP-generated documentation queries to Context7/Upstash;
   • users should not send sensitive, health or other regulated data through the integration;
   • an API key, when used, stays in Codex-private persistent state and is never printed by Remote Dev;
   • Context7 availability/output accuracy is external and non-fatal to Remote Dev/Codex startup;
   • users remain responsible for the original licenses/terms of documentation returned by Context7.

   Official sources reviewed on 2026-08-09:

   • OpenAI Codex MCP docs (developers.openai.com/codex/mcp, currently redirecting to the current ChatGPT Learn MCP documentation)
   • Context7 MCP repository/docs (github.com/upstash/context7, context7.com/docs)
   • Context7 security/data-privacy docs
   • Upstash legal index, Context7 Addendum, Terms of Service and Privacy Policy

   This satisfies the #53 out-of-cycle review gate for the bounded hosted-MCP design in #94. Re-review is required if #94 later starts redistributing Context7 code/packages, switches authentication/transport, or if the hosted terms/privacy materially change.
5. eXPerience83 commented on Aug 16, 2026

   

   eXPerience83

   on Aug 16, 2026 – with ChatGPT Codex Connector

   OwnerAuthor

   More actions

   2026-08-16 — out-of-cycle Context7 device-login review for #123

   Reviewed the new authentication/supply-chain boundary proposed for #123 against the current Context7 upstream source/package contract and current Upstash legal documents.

   Exact implementation boundary reviewed

   • Remote Dev keeps the already-reviewed feat: add optional Context7 integration for the Codex service #94 hosted MCP runtime contract and private managed-key storage; this review does not approve replacing it with native MCP OAuth or a vendor-owned Codex configuration.
   • Device onboarding uses only the currently published ctx7@0.5.7 package and the vendor-native ctx7 login --no-browser flow.
   • Current upstream 0.5.7 auth code uses the RFC 8628 device flow and stores the successful new-install credential as a long-lived bearer API key in the ctx7sk-... form. Remote Dev validates that exact credential shape before adoption.
   • Remote Dev deliberately does not invoke ctx7 setup: current upstream setup can create another API key and modify agent MCP config/rules/skills, including plaintext agent configuration paths that do not match our feat: add optional Context7 integration for the Codex service #94 ownership model.
   • The transient CLI runs only after explicit user action in a fresh private /run subtree, with a fresh HOME/XDG/npm cache, telemetry disabled, npm lifecycle scripts disabled, user/global npm config ignored, and the public npm registry fixed explicitly.
   • When the service is root, transient vendor code is dropped to the fixed unprivileged nobody identity with no-new-privs. It receives no Codex/OpenAI/GitHub/current-Context7 credential environment and no real CODEX_HOME.
   • Only the resulting API key is passed over child-process stdin to the existing Remote Dev manager. The CLI package, npm cache and vendor login state are recursively removed on success/failure/cancellation and are not part of the immutable image, persistent state or build-time SBOM.
   • A working previous Remote Dev-managed key is not replaced until the new login has succeeded and the private credential file has passed ownership/mode/type/shape validation.
   • remote-dev-context7 remove remains local-only. A device-created account-side API key is not claimed to be revoked; users must rotate/revoke it through Context7 account controls when desired.

   Distribution / license / provenance

   The upstream Context7 repository and CLI package are MIT-licensed. This implementation does not redistribute the ctx7 package: npm obtains it directly from the fixed public registry during an explicit user action and Remote Dev does not retain its bytes.

   The top-level CLI version is exact rather than latest, but its npm dependency graph is not a repository-committed immutable lock: upstream package dependencies include semver ranges. That is a deliberate remaining supply-chain limitation of this optional transient onboarding path. Mitigations are the explicit-only invocation, fixed package version and registry, disabled lifecycle scripts, credential-minimized unprivileged execution, private disposable filesystem state and full cleanup. If future review requires an immutable transitive dependency closure, that should be implemented explicitly rather than pretending the current npm execution provides it.

   Terms / privacy re-check

   The current Upstash legal index still identifies the Upstash Terms of Service, Privacy Policy and Context7 Addendum as the applicable documents. The Context7 Addendum remains effective August 2025 and expressly covers MCP/API use by developers/AI assistants, requires protecting account credentials/API keys, prohibits sensitive/health/regulated inputs and unauthorized credential distribution, and treats Context7 Inputs/usage as Customer Data under the Upstash privacy terms. The main Terms remain last updated April 2025 and assign account/API credential security responsibility to the user; the Privacy Policy remains last updated April 2025.

   Device login adds an account-authentication exchange and creation/adoption of an account-side API key, so the user-facing docs must disclose that this is an external Upstash/Context7 flow and that local removal does not revoke the account-side key. The existing #94 warning not to send sensitive/regulated data remains applicable.

   Review result

   No new redistribution/license blocker was found for the bounded implementation above. The #123 out-of-cycle legal/privacy/supply-chain review gate is satisfied for this exact design. Any change to a different ctx7 version, registry/source, ctx7 setup, native MCP OAuth, retained CLI package, different credential type, or broader vendor filesystem/credential access requires re-review.

   This review does not substitute for the still-required exact-candidate CI and real TrueNAS device-login/lifecycle validation before #123 can merge.
6. eXPerience83 commented on Aug 17, 2026

   

   eXPerience83

   on Aug 17, 2026 – with ChatGPT Codex Connector

   OwnerAuthor

   More actions

   2026-08-17 — #136 implementation hardened within the approved Context7 boundary

   Rechecked PR #136 after syncing it with merged #135. The current exact head is 524aec2b8d4302e514a990bf1f644afd1c532315.

   Manual security review tightened the implementation to match the already-approved #123 boundary: cleanup failure now blocks key adoption; transient temp/XDG runtime state is contained under the private /run root; vendor execution uses an isolated process group with bounded termination/reaping; privileged credential reads validate each path component with O_NOFOLLOW so vendor-controlled parent symlinks cannot redirect the read; and synthetic regressions cover those cases.

   This does not change the reviewed supply-chain/legal design: still exact ctx7@0.5.7, only ctx7 login --no-browser, no ctx7 setup, no native MCP OAuth, no retained vendor package/state and no expanded credential/filesystem access. Therefore this is recorded as implementation hardening, not a new out-of-cycle review trigger.

   Exact-head Build AMD64 #996 is green and CodeRabbit completed a full technical review with no source-level findings. Real TrueNAS validation remains pending before merge.
7. eXPerience83 commented on Aug 17, 2026

   

   eXPerience83

   on Aug 17, 2026 – with ChatGPT Codex Connector

   OwnerAuthor

   More actions

   Context7 #123 privacy/supply-chain record correction for PR #136, current exact head 251037b2a9aa0836cd97c18ee0cc5f705fff4cee.

   Reviewing the exact upstream ctx7@0.5.7 device-login source exposed one data-flow detail that was not explicit in the 2026-08-16 record: the official device-authorization request sends os.hostname() on a best-effort basis so Context7 can identify the device on the browser-side verification page. After authorization, the CLI uses the newly issued key for a Context7 whoami request and may display account identity/teamspace in the local terminal.

   The English and Spanish Context7 docs now disclose both behaviors and continue to require redaction of local account identity, device codes and credentials from validation evidence. Remote Dev does not persist the CLI output.

   This corrects/completes the data-flow disclosure; it does not change the approved architecture or broaden the vendor boundary: exact top-level package remains ctx7@0.5.7, only ctx7 login --no-browser is invoked, vendor state remains transient, no existing Codex/OpenAI/GitHub/Context7 credential is inherited, execution remains unprivileged when root, and only the resulting reviewed long-lived ctx7sk-... API key may be adopted into the existing #94 manager path after validation/cleanup.

   Also verified against exact primary upstream source that the new device flow returns the same long-lived ctx7sk-... API-key form as the legacy flow. The broader upstream credential type retains refresh/expiry fields for legacy OAuth compatibility; PR #136 intentionally continues to reject those fields rather than silently expanding the reviewed credential lifecycle.

   No new legal blocker is identified from this correction. A change to package/version/source, auth model, retained state, hostname/account-data behavior, credential type/lifecycle or filesystem/credential access still requires re-review under this tracker.
8. eXPerience83 commented on Aug 17, 2026

   

   eXPerience83

   on Aug 17, 2026 – with ChatGPT Codex Connector

   OwnerAuthor

   More actions

   2026-08-17 — Context7 0.5.8 + reviewed/latest admission re-review for #123

   Re-reviewed the Context7 transient-CLI boundary before changing PR #136 from a single reviewed pin to the same reviewed-vs-latest model already used conceptually by the optional Codex/Antigravity runtimes.

   ctx7@0.5.8 review

   • official upstream tag ctx7@0.5.8 resolves to commit f17ed6a455c49c41cb2e5c784b2d69cdb0d0c720;
   • packages/cli/src/commands/auth.ts is byte-identical between ctx7@0.5.7 and ctx7@0.5.8, so the login --no-browser device authorization, hostname disclosure, credential write and post-login identity display used by Remote Dev are unchanged;
   • the CLI dependency list is unchanged; package metadata remains ctx7, MIT, Node >=18;
   • the 0.5.8 CLI changelog/change is bounded to refreshing expired legacy OAuth credentials for other CLI commands and retaining an existing refresh token when the refresh response omits it. New device login still produces the long-lived API-key path Remote Dev already validates, and Remote Dev continues to reject refresh/expiry credential state.

   0.5.8 is therefore accepted as the new Remote Dev-reviewed Context7 CLI version for this onboarding surface.

   Reviewed vs latest official model

   The proposed runtime selector does not bundle or persist Context7 CLI bytes. For an explicit device login it may offer either:

   1. the committed Remote Dev-reviewed exact version; or
   2. the exact version currently resolved from the public npm ctx7 latest metadata, clearly labelled official source; Remote Dev review pending if it differs.

   A newer version is not blocked merely because human review is pending, matching the established optional-runtime availability principle. It is still fail-closed on the actual trust/compatibility boundary: fixed public npm registry, exact package name/version, stable-semver format, expected MIT package-license metadata, npm integrity metadata, isolated/unprivileged execution, no lifecycle scripts, no inherited agent credentials, only ctx7 login --no-browser, expected long-lived ctx7sk-... credential shape, and complete transient-state cleanup before adoption. latest is resolved first and execution then names that exact version rather than executing a mutable @latest specifier.

   This does not change the hosted MCP contract, credential persistence model, service terms boundary, or normal Codex launch behavior. Future package releases remain review pending until the repository's upstream-review automation proposes the reviewed pin update; a material change in license, source/origin, authentication/credential model, retained state, data disclosure or filesystem/credential access still triggers this tracker rather than being silently normalized.
9. eXPerience83 commented on Aug 27, 2026

   

   eXPerience83

   on Aug 27, 2026 – with ChatGPT Codex Connector

   OwnerAuthor

   More actions

   2026-08-27 — #96 current-installer / terms / privacy reconciliation evidence

   Re-reviewed the Antigravity boundary after the real TrueNAS current-installer admission completed under #96/#29.

   Distribution and runtime boundary remains unchanged

   Remote Dev still:

   • does not bundle, mirror or redistribute the Antigravity installer or agy binary;
   • downloads only from Google's documented official CLI installer endpoint after explicit user action;
   • stores the resulting executable only in Antigravity-private persistent state, outside immutable image layers/build-time SBOM claims;
   • launches the official agy CLI rather than implementing an alternate client for Antigravity's service;
   • does not extract, copy, reuse or expose Antigravity OAuth tokens/cookies to another agent/service;
   • does not call Antigravity service backends directly;
   • keeps normal launches independent of the installer endpoint and keeps vendor self-update disabled.

   The real 2026-08-27 TrueNAS pass admitted Google's then-current payload through the shipped #96 contract:

   Antigravity updated explicitly: 1.1.19 -> 1.1.22
   Review state: official source; Remote Dev review pending.
   Antigravity runtime full integrity: OK (1.1.22)
   

   A real authenticated launch of official CLI 1.1.22 succeeded afterward, and #29 subsequently proved the same persisted runtime remained usable across the controlled Remote Dev image rollback/return.

   Current official Google docs reviewed

   As of this review, Google's own documentation explicitly supports:

   • installation/upgrades from https://antigravity.google/cli/install.sh;
   • a remote SSH OAuth flow where the official CLI prints an authorization URL and the user pastes the resulting code back into the remote terminal;
   • official CLI headless/CI use with cached CLI credentials;
   • programmatic/headless flags such as --print, --continue and --conversation;
   • disabling the CLI self-updater with AGY_CLI_DISABLE_AUTO_UPDATE=true.

   Sources:

   • https://antigravity.google/docs/cli/install/
   • https://antigravity.google/docs/cli/headless/
   • https://antigravity.google/docs/cli/troubleshooting/

   These current docs are consistent with Remote Dev's technical model of operating the official CLI in a remote/containerized developer terminal rather than reimplementing Antigravity authentication or model access.

   Current terms/privacy boundary

   The current Antigravity Additional Terms state broadly that using third-party software/tools/services to access the Service is prohibited, with OpenClaw with Antigravity OAuth as an example:

   • https://antigravity.google/terms
   • https://antigravity.google/docs/faq/

   The same terms also state that Google records/stores Interactions and may use them for product/model improvement unless the user changes the applicable setting; Remote Dev therefore must continue to link Google's terms/privacy and must not imply that repository/prompt data remains solely local merely because the CLI itself runs locally.

   A Google AI Developers Forum thread asks almost the exact integration question relevant here: a third-party developer tool launching the official unmodified agy binary, delegating all authentication to it, never touching OAuth tokens and never calling Antigravity backends directly. A community reply says that usage is fine and distinguishes it from running Antigravity-account models in another harness. However, the reply is from a community participant, not identified as authoritative Google legal/product guidance, so it is useful context but not sufficient by itself to treat the terms question as formally resolved:

   https://discuss.ai.google.dev/t/is-invoking-the-official-antigravity-cli-agy-print-from-a-third-party-developer-tool-an-acceptable-use/175462

   Review decision/status

   Supply-chain, installer, authentication, privacy-disclosure and non-redistribution evidence for #96 is now complete and consistent with the shipped implementation.

   One human terms-interpretation decision remains before marking the #96 out-of-cycle review-log item complete: whether Remote Dev's role as a container/terminal launcher for the unmodified official CLI is accepted as outside the prohibited “third-party software ... to access the Service” scenario, or whether explicit clarification from Google should be requested first.

   I am deliberately not marking that legal interpretation as approved automatically. No additional TrueNAS testing is required for #96; the remaining gate is this narrow human decision. Keep #53 open as the standing review tracker regardless.
10. eXPerience83 commented on Aug 27, 2026

    

    eXPerience83

    on Aug 27, 2026 – with ChatGPT Codex Connector

    OwnerAuthor

    More actions

    2026-08-27 — lower-ambiguity fallback identified, not adopted

    One additional official-doc finding is relevant if the remaining human terms interpretation decides that account-based Antigravity OAuth should not be exposed through Remote Dev.

    Google's current official Antigravity CLI now supports running the same agy binary with a user-provided Gemini API key instead of an Antigravity account session. The docs state that in this mode requests go directly to the Gemini API and the CLI never establishes an account session; configuration uses modelProvider: "gemini" in ~/.gemini/antigravity-cli/settings.json plus GEMINI_API_KEY in the process environment. The Antigravity FAQ separately recommends a Vertex or AI Studio API key when users want a third-party coding-agent path.

    Official references:

    • https://antigravity.google/docs/cli/install/#using-a-gemini-api-key
    • https://antigravity.google/docs/faq/

    This is not a recommendation to change Remote Dev now: it changes account/quota/billing and credential-management semantics and has not been designed or validated here. Keep the current implementation unchanged pending the human #53/#96 decision.

    If account-OAuth use is judged too ambiguous under the current terms, the API-key mode is a plausible separately reviewed fallback that still executes Google's official CLI and avoids reuse of an Antigravity account session. That should become a focused issue only if the owner chooses that policy; do not silently switch existing users or broaden #96.
11. eXPerience83 commented on Aug 29, 2026

    

    eXPerience83

    on Aug 29, 2026 – with ChatGPT Codex Connector

    OwnerAuthor

    More actions

    2026-08-29 — out-of-cycle ttyd frontend review for #173 / PR #175

    Human review completed and accepted for the bounded project-owned ttyd 1.7.7 client asset introduced by PR #175.

    Distribution / provenance boundary reviewed

    • Stable ttyd remains 1.7.7; the server binary is unchanged.
    • The redistributed client is deterministically derived from ttyd commit 40e79c706be14029b391f369bee6613c31667abb and exact src/html.h/embedded-HTML hashes, then receives only the bounded Remote Dev OSC 52 write handler.
    • The final client asset remains byte-stable at SHA-256 84724f4f4e63b559631ace65df3f21f2941b1dd8199b76f78ca3d5f9e07aadd8 after the legal-evidence correction.
    • The exact ttyd 1.7.7 zmodem.js 0.1.10 Yarn patch is preserved separately, hash-bound to the source archive/commit and identified as an upstream modification.

    Redistributed-code closure reviewed

    The review distinguishes build-only tooling from code physically emitted in the client bundle. The recorded closure is:

    • 15 exact Webpack-root components from the ttyd 1.7.7 frontend; plus
    • 4 components already prebundled into trzsz 1.1.5/lib/trzsz.js: base64-js 1.5.1, pako 2.1.0, ts-md5 1.3.1, and tslib 2.6.2.

    That gives 19 redistributed third-party components for this standalone client asset. The nested closure was checked against the exact trzsz source/build configuration and lock data; Rollup uses node resolution/commonjs for lib/trzsz.js, while the emitted source imports Pako/base64-js and ts-md5. Build/test-only tooling is not promoted into the redistribution inventory merely because it appears in trzsz devDependencies.

    License / notice evidence reviewed

    • MIT terms are preserved for the applicable ttyd/xterm/frontend components and the nested base64-js / ts-md5 / Pako JS contribution.
    • Pako 2.1.0 is represented as MIT AND Zlib; its root MIT license and the lib/zlib Zlib notice are both preserved.
    • tslib 2.6.2 is correctly represented as 0BSD, with its license/copyright evidence preserved.
    • crc-32 1.2.0 and zmodem.js 0.1.10 are represented as Apache-2.0. The zmodem upstream repository/tag contains the Apache license and no separate NOTICE file was identified; ttyd's modification is separately recorded by patch provenance.
    • The dedicated SPDX 2.3 document represents the 19-component closure plus the aggregate client package under MIT / Apache-2.0 / Zlib / 0BSD component terms.
    • The repository inventory points to the exact ttyd source commit and to the preserved client notice directory. The Docker build copies that third_party evidence into the image, and remote-dev-notices --check verifies the notice paths.

    Validation / SBOM review

    Exact implementation head 19f8b188fba4313969b2f0e874ba5f13a15163c4 passed repository validation, build/smoke, bundled-notice checks, base/final SPDX SBOM generation, base/final Trivy scans and the no-fixable-critical gate. The generated image SBOMs do not enumerate the standalone/minified ttyd frontend packages individually; that limitation is already documented by the repository, so the dedicated hash-bound frontend inventory/SPDX is the authoritative closure for this asset rather than pretending the generic image SBOM is a perfect standalone-bundle detector.

    The final source-level check also confirmed that exact ttyd 1.7.7 assigns the xterm instance via window.term = terminal in Xterm.open(), so PR #175's pre-bundle window.term setter installs against the actual pinned upstream lifecycle rather than an assumed hook. ttyd reconnect reuses that terminal instance.

    No new legal/supply-chain blocker was identified in the final review. The owner explicitly approved the #53 out-of-cycle review for PR #175 after this inspection. third_party/inventory.json.reviewed_on is therefore updated to 2026-08-29 in the same PR; #53 remains open as the standing review tracker.

    Re-review remains required on the normal #53 cadence and before stable releases, and immediately if the ttyd/frontend version, emitted dependency closure, license/NOTICE text, patch/provenance, packaging or distribution boundary changes. #174 remains the explicit compatibility/removal review before any ttyd upgrade.
12. eXPerience83

    added a commit that references this issue on Aug 30, 2026

    fix: complete native Codex copy to client clipboard (#175)

    ...

    eccd708
13. eXPerience83 commented on Sep 3, 2026

    

    eXPerience83

    on Sep 3, 2026 – with ChatGPT Codex Connector

    OwnerAuthor

    More actions

    2026-09-03 — #96 current Google terms/docs recheck; human decision narrowed

    Re-checked the current official Google Antigravity terms, FAQ and CLI documentation before asking the owner for the final #96 policy disposition.

    Current official terms/FAQ

    The Additional Terms still contain the broad restriction that the Service must not be used “in connection with products not provided by us” and state that using third-party software/tools/services to access the Service (example: OpenClaw with Antigravity OAuth) breaches the agreement and may lead to suspension/termination.

    The current official FAQ makes the intended abuse case more concrete: it names Claude Code, OpenClaw and OpenCode used with an Antigravity login as prohibited third-party access, and recommends a Vertex/AI Studio API key when a user wants a third-party coding agent to use Gemini.

    Official references reviewed on 2026-09-03:

    • https://antigravity.google/terms
    • https://antigravity.google/docs/faq/

    Current official CLI documentation materially narrows the ambiguity

    Google now/currently documents Antigravity CLI itself as an official terminal-first surface and explicitly supports usage patterns that are structurally close to Remote Dev's environment:

    • the official Linux/macOS installer remains https://antigravity.google/cli/install.sh;
    • the CLI has an explicit Remote SSH OAuth flow, where agy runs on a remote machine and authentication is completed in a browser elsewhere;
    • official headless mode is documented for scripting agent tasks, programmatic stdin/stdout use and integration with CI pipelines;
    • headless mode can use credentials cached by the official CLI after an interactive authentication;
    • Google also documents an API-key mode as a separate option for headless/CI use;
    • the CLI has an official plugin/skills/MCP extensibility model.

    Official references reviewed on 2026-09-03:

    • https://antigravity.google/docs/cli/install/
    • https://antigravity.google/docs/cli/headless/
    • https://antigravity.google/docs/cli/overview/
    • https://antigravity.google/docs/cli/plugins/

    Remote Dev's actual boundary remains on the lower-risk side of that distinction

    Remote Dev still:

    • does not implement an alternate Antigravity/Gemini service client;
    • executes Google's official agy binary rather than speaking Antigravity backend protocols itself;
    • delegates account authentication to the official CLI;
    • does not extract, copy, proxy, reuse or expose Antigravity OAuth tokens/cookies to Codex, launcher or another harness;
    • does not call Antigravity service/model backends directly;
    • does not circumvent quotas/rate limits;
    • does not bundle or redistribute Google's installer/binary;
    • uses the official installer only after explicit user action and keeps normal launches on the persisted official binary.

    This is materially closer to “run the official CLI in a remote terminal / script / CI environment”, which Google explicitly documents, than to the FAQ's prohibited pattern of using an Antigravity account/login to power a different coding-agent harness.

    What is still not resolved automatically

    The broad phrase “in connection with products not provided by us” is still present. There is still no identified authoritative Google legal/product response specifically saying that a third-party container/terminal launcher around the unmodified official CLI is permitted. The existing Google AI Developers Forum reply to the near-identical agy --print launcher question is useful context but is from a community participant, not authoritative Google guidance.

    Therefore this evidence reduces the ambiguity but does not convert it into an automatic legal approval.

    Recommended conservative disposition for the owner's human decision

    A reasonable low-claim project policy would be:

    1. accept the current Remote Dev integration as an experimental wrapper/launcher for the official CLI, not as an alternate Antigravity client;
    2. keep Antigravity optional/experimental and explicitly non-affiliated/non-endorsed;
    3. keep linking Google's current Terms/Privacy before explicit installation/update;
    4. state that Google account/service terms govern use and may change;
    5. never reuse Antigravity account OAuth outside the official CLI or relay its service through another agent;
    6. do not claim that the documented remote/headless CLI workflows constitute Google approval of Remote Dev specifically;
    7. keep API-key/provider mode as a separately reviewed fallback if account-session use later becomes clearly disallowed or operationally risky.

    Alternative conservative disposition: require explicit written clarification from Google before making any stronger support claim. No code change is needed for either choice today.

    Remaining #96 gate is now only the owner's human policy choice between those two dispositions. No additional TrueNAS technical testing is indicated by this review.
14. eXPerience83 commented on Sep 3, 2026

    

    eXPerience83

    on Sep 3, 2026 – with ChatGPT Codex Connector

    OwnerAuthor

    More actions

    2026-09-03 — human Antigravity policy/terms reconciliation for #96

    Owner decision: accept disposition A for the current Remote Dev Antigravity integration.

    Interpretation recorded

    Remote Dev may continue to expose Antigravity as an experimental optional integration because the implemented model launches Google's official agy CLI inside the isolated Remote Dev role container rather than implementing an alternative Antigravity service client, impersonating the official client, or reusing Antigravity/Google OAuth credentials for another coding agent or service.

    The current official CLI documentation materially supports terminal/remote usage patterns including remote SSH/headless/automation scenarios. At the same time, current Google terms/FAQ contain broader third-party-tool wording whose application to an official-CLI container/wrapper is not perfectly explicit. The project therefore records this as a human risk/policy interpretation, not as vendor legal approval, certification or endorsement.

    Required support restrictions

    The accepted project policy is:

    • keep Antigravity explicitly experimental;
    • use only the official Google agy CLI/runtime obtained through the reviewed official-source path;
    • do not implement an alternative Antigravity protocol/service client;
    • do not reuse or export Antigravity/Google OAuth credentials for Codex, OpenCode, OpenClaw, Claude Code or any other third-party agent/service;
    • keep installation/update explicit and user initiated;
    • keep AGY_CLI_DISABLE_AUTO_UPDATE=true for supported Remote Dev sessions;
    • do not redistribute Google installer/CLI proprietary bytes in Remote Dev images or the repository;
    • retain isolated role-private credentials/state and the security: define review-pending Antigravity runtime admission #96 manifest/integrity/admission safeguards;
    • retain clear non-affiliation/non-endorsement wording and applicable Google terms/privacy disclosures;
    • do not describe official source; Remote Dev review pending as Google signing, Remote Dev certification or vendor approval;
    • re-open/out-of-cycle review under maintenance: recurring third-party license and distribution review #53 if Google materially changes the terms, FAQ, privacy/auth model, installer origin/behavior or official CLI usage guidance.

    No concrete implementation or distribution defect was identified by this reconciliation, so the existing #96 runtime-admission safeguards should remain unchanged.

    Disposition

    This completes the outstanding human #53 reconciliation required by #96. #53 remains open as the standing six-month/out-of-cycle review log. Antigravity remains experimental until the public documentation/support wording is synchronized under #92; this decision does not promote it to a vendor-supported or stable integration.
15. eXPerience83 commented on Sep 4, 2026

    

    eXPerience83

    on Sep 4, 2026 – with ChatGPT Codex Connector

    OwnerAuthor

    More actions

    2026-09-04 — Context7 0.5.9 transient-login re-review for PR #197

    Re-reviewed the exact ctx7@0.5.9 upstream boundary before promoting the transient device-login reviewed pin from 0.5.8 to 0.5.9.

    • upstream annotated tag ctx7@0.5.9 resolves to commit 0ff958c9f038d66be030ab72094cef0e4ca40bf3;
    • the exact packages/cli/src/commands/auth.ts blob is unchanged from 0.5.8 (df893109561cf5ce96636ed25ce2bf01a9331108), so ctx7 login --no-browser, device authorization, hostname disclosure path, token persistence behavior and post-login whoami display are unchanged;
    • packages/cli/package.json changes only the package version from 0.5.8 to 0.5.9: package name remains ctx7, license MIT, Node requirement remains >=18, and runtime dependencies are unchanged;
    • the 0.5.9 CLI changelog contains two patch changes: Git Bash library-ID recovery and preserving existing Codex TOML settings while rotating stdio API keys. The implementation changes are in library-ID/setup/TOML paths; Remote Dev deliberately does not invoke ctx7 setup and continues to invoke only ctx7 login --no-browser in the isolated transient onboarding boundary;
    • PR chore: review upstream updates #197 pins the exact npm SRI from the fixed public registry and Build AMD64 validates the reviewed version/integrity contract; the CLI remains transient, unbundled and outside the immutable image/build-time SBOM.

    Current Context7 legal boundary remains the previously reviewed Upstash Terms/Privacy + Context7 Addendum (effective August 2025); no material service/auth/data-handling change was identified for this exact login surface. No new distribution/license/privacy blocker is identified for 0.5.9 under the existing #123/#94 restrictions.

    Re-review remains required for a later package/source/license change, a change to the auth/device-flow code or credential shape/data disclosure, use of ctx7 setup, native MCP OAuth, retained vendor package/state, or broader filesystem/credential access.
16. eXPerience83

    added a commit that references this issue on Sep 4, 2026

    release: add Renovate provenance for Ubuntu image updates (#200)

    ...

    22a3bda
17. eXPerience83 commented on Oct 18, 2026

    

    eXPerience83

    on Oct 18, 2026 – with ChatGPT Codex Connector

    OwnerAuthor

    More actions

    2026-10-18 — PR2 #281 targeted owner sign-off: redistribution/licensing and image-size budget

    Decision: The project owner has explicitly approved proceeding with PR #281 after the exact-head CI/review audit, including (1) the incremental uncompressed image-size exception above the 50 MiB soft threshold in #121, and (2) continued redistribution of the identified additional open-source toolchain components under their preserved upstream terms/notices. This approval is specific to PR2 and is not a legal opinion or a blanket approval of future versions/dependencies.

    Scope reviewed: final reviewed source head d242caa7cab77b08d115c6bc6b77d7e25440622b. Six approved user-facing tools: Ruff 0.17.1, pytest 9.1.1, pre-commit 4.7.0, Mike Farah yq 4.54.1, shfmt 3.14.1, actionlint 1.7.12. Existing global Python 3.14.8/3.15.0 remain unpolluted; three isolated hash-locked Python CLI graphs. Native Aqua assets retain locked AMD64/ARM64 identities, checksums and supported provenance metadata.

    Attribution/distribution evidence reviewed: third_party/inventory.json, third_party/components/python-clis/manifest.json, 17 transitive Python package entries each with hash-bound wheel-derived NOTICES.txt, including embedded virtualenv seed-wheel notices; nine inspected standalone components overall, including three new native tools (both architectures). Reported license families for the new graphs and native CLIs are permissive MIT/BSD/Apache/PSF variants; files with verbatim upstream license/notice texts are retained. The exact-head Build AMD64 checks remote-dev-notices --check in base/final, produces SPDX SBOMs and applies Trivy gates, including 0 CRITICAL reported. No new vendor OAuth, proprietary Antigravity redistribution, hosted-service terms, containers/host privileges or credential boundaries are introduced.

    Explicit size budget exception: exact original CI before/after measurement versus main 6a0fdf2c917a3b4ac62fc2ccfd91c1646ad0c77b = base +73,826,162 bytes (+70.41 MiB); final +71,362,060 bytes (+68.06 MiB), ~4.31% final-image increase. Both exceed the 50 MiB advisory threshold. Accepted as a justified trade-off for six pre-CI, audited, immutable CLI capabilities rather than removing provenance/notice/isolated-environment guarantees. Compressed pull-size increase has not been measured. The exceptional before/after comparison remains manually opt-in and does not burden normal CI.

    Technical review and limits: source head is mergeable/up to date, exact-head PR build, default manual build and offline contract CI passed. CodeRabbit status Review completed, no open review threads, prior actionable finding resolved. Tests model role fixtures, not a completed authenticated real-agent TrueNAS acceptance. Owner-approved review is limited to the additional PR2 distribution changes and does not replace a full periodic #53 audit: leave global third_party/inventory.json.reviewed_on unchanged until the next comprehensive review. Keep #53 open for routine/out-of-cycle updates. On new versions or changed license/packaging, re-review as required.

    Release boundary: squash merge authorized. That main-push can trigger the reviewed experimental edge publication workflow, never the stable channel. Confirm post-merge publication checks and conduct separate real TrueNAS user acceptance; no TrueNAS changes are made by recording this decision.
18. eXPerience83

    added a commit that references this issue on Oct 18, 2026

    feat: add locked universal validation CLIs (PR2) (#281)

    ...

    5a56c30
19. eXPerience83 commented on Oct 21, 2026

    

    eXPerience83

    on Oct 21, 2026 – with ChatGPT Codex Connector

    OwnerAuthor

    More actions

    2026-10-21 out-of-cycle CA security update: exact redistributed runtime terms (#284 / PR #286)

    Security-driven replacement of the two bundled Python standalone build revisions and uv's vendored trust store. This is an engineering notice/inventory audit, not an independent legal opinion.

    • Security advisories from 2026-10-20: certifi GHSA-6q48-6c7w-9gw2 and uv GHSA-hq85-5cpj-mr62. Old base/final SPDX explicitly included pip 26.2.1, certifi 2026.6.17 and uv 0.13.1.
    • PR security: repin CA-safe Python distributions and uv (#284) #286 retains Python 3.14.8 and 3.15.0 and existing read-only/project-selection contracts; switches the four installed AMD64/ARM64 Python assets to verified python-build-standalone 20261020 release metadata (official checksum and GitHub attestations), which bundles upstream pip 26.2.2. Upgrades uv to 0.13.4 using both exact asset digests/provenance; unchanged MIT/Apache license text verified bytewise between uv versions 0.13.1 and 0.13.4.
    • One-shot legal regeneration fetched verified full Python archives for both lines and architectures, extracted the actual legal metadata/licence files and generated compact summaries. All six changed JSON manifest/metadata files were committed with Git blob-SHA equality to that artifact; the two obsolete OpenSSL-1.1 texts were removed because the new full archives don't reference them. All other preserved legal text files remained identical to the existing repository, as confirmed by git status after regeneration.
    • Repeat independently re-generating against committed records completed successfully with no changed Python legal files, demonstrating reproducibility. The fixed synchronizer permits zero supplemental downloads only when the upstream full archive itself already contains the approved formerly missing zlib-ng/zstd texts; unknown URLs/digests remain rejected by a regression test. The one-time audit workflow is removed from the candidate merge diff.
    • third_party/inventory.json.reviewed_on remains 2026-08-29: this is a targeted out-of-cycle update, not a full global legal review. refreshed_on becomes 2026-10-21.
    • The final security CI gate and CodeRabbit are still running at the time of this entry. No new stable release/TrueNAS operation or human legal signoff is claimed here. Any new notices introduced by final scans/review must be reconciled before merge.

    Links: #284 and PR #286.