Skip to content

fix(server): Claude and Grok update only through the install that owns them - #272

Merged
lukemaj merged 3 commits into
mainfrom
fix/263-provider-update-owners
Oct 14, 2026
Merged

lukemaj merged 3 commits into
mainfrom
fix/263-provider-update-owners

Conversation

@lukemaj

@lukemaj lukemaj commented Oct 14, 2026 •

Copy link
Copy Markdown
Contributor

What: Claude and Grok auto-updates now go through the installer that owns the binary: a Homebrew grok-build cask upgrades through brew upgrade --cask grok-build, and a mise-managed Claude (any ~/.local/bin mise launcher) is left to mise instead of running claude update.
Why: claude update matched ~/.local/bin/claude before the mise checks ran, so on bestia it no-op'd on every start. And grok update on a cask install only writes an unused copy under ~/.grok/bin, so rocky stayed on 1.0.13 (upstream pingdotgg/t3code#18768).
So what: This takes effect on each machine at its next Chromeria deploy. bestia's provider CLIs are now native installs (runbook b639b21), and Chromeria's auto-update keeps them current. Its 09:30 run already upgraded OpenCode there.

Refs #263 (stays open for the post-deploy bestia boot-log check).

Problem

resolvePackageManagedProviderMaintenance returned the native updater for any path the driver called native before it checked mise paths and wrappers, so bestia's mise launcher at ~/.local/bin/claude got claude update, which mise owns and Claude refuses. Grok's own resolver always returned <grok> update, which is wrong for the Homebrew cask.

Change

  • Port of upstream fix(grok): a Homebrew-installed Grok updates through brew and is compared against the cask pingdotgg/t3code#18772 (open, head d39ca4a): the Homebrew branch moves unchanged into an exported resolveHomebrewProviderMaintenance. Grok's resolver checks a cask first: a verified grok-build cask gets brew upgrade --cask grok-build, lock key homebrew, and is compared against the cask version (,build dropped). A cask that the found brew cannot verify stays manual-only. Any other Grok keeps grok update with the instance env. That is correct for npm and mise-npm Grok: the npm package is a bootstrap that runs ~/.grok/bin/grok, which grok update updates. Chromeria auto-updated bestia's Grok this way at 08:03 today.
  • Port of upstream fix(providers): respect mise ownership in native install locations pingdotgg/t3code#19157 (open, head cb3d9a3): the native shortcut applies only when no command path is a mise path and the file is not a mise launcher.
  • Fork addition (from review): the native shortcut also refuses a real path inside the Homebrew mise keg (a mise shim linked to a native-looking path, e.g. ~/.local/bin/claude -> <prefix>/Cellar/mise/<v>/bin/mise). An earlier head widened launcher detection to mise where|which; that heuristic was removed after review, because shell text cannot reliably tell commands from comments or heredoc data, and bestia's exec-by-path launchers that needed it were retired today. Launcher detection is upstream's mise x|exec check, unchanged.
  • Fork allowlist and the provider-auto-update owner in docs/fork-features.md list the four touched upstream files.

Upstream #14949 (Chromeria running mise upgrade) was considered and not ported. On bestia every provider is reached through a launcher that Chromeria probes every 5 minutes, and those launchers now run mise install <tool>@latest, so mise keeps them current with no new Chromeria machinery.

Proof

  • npx -y pnpm@11.10.0 exec vp test run apps/server/src/provider/Drivers/GrokDriver.test.ts apps/server/src/provider/providerMaintenance.test.ts: 45 passed on 38d1c10 (base 54fb0fc).
  • On 7672551, the new tests fail for the intended reason. The cask spawned no brew and returned grok update. The mise launcher and mise-install cases returned claude update (lock key claudeAgent-native) instead of manual-only. The node-keg Grok and the real native Claude symlink (~/.local/bin/claude -> ~/.local/share/claude/versions/2.1.299) pass before and after.
  • Targeted lint on the four source files: clean. tsc --noEmit for the server package: exit 0.
  • Live, on the deployed 0.0.45, no restart: Chromeria's own auto-updater updated a provider on each machine today.
    • cavallo: nvm codex was pinned back to 0.162.0, then a root-level updateProvider span at 07:08:37Z brought it to 0.162.1.
    • rocky: native Claude was pinned back to 2.1.296, then a root-level span at 07:13:36Z brought it to 2.1.299.
    • bestia: the Updating provider automatically { driver: 'grok' } line at 08:03:49 CEST was followed by grok-1.0.52 at 08:03:52.
  • Not yet proved: the bestia boot-log check from Provider auto-update runs self-updaters that leave the running Claude and Grok stale #263 (no Claude or Grok attempt across a restart). That needs a deploy, which was out of scope here.

Elon record

  • Requirements and who asked: Make provider auto-update actually update the binary Chromeria runs on bestia, rocky and cavallo, and prove Chromeria itself updating a provider on each (planner and user, 2026-10-14; Provider auto-update runs self-updaters that leave the running Claude and Grok stale #263).
  • Deleted: Chromeria-side mise upgrades (upstream #14949, 15 files): mise launchers now upgrade themselves. Persisted update state and outcome logging (Provider auto-update runs self-updaters that leave the running Claude and Grok stale #263 non-goals).
  • Bottleneck: Install-ownership resolution that picked the updater: the native shortcut before the mise checks, and Grok's resolver with no Homebrew check.
  • Checked myself: Read the upstream diffs for #18772 and #19157 and the #14949 description. Tested mise behaviour in an isolated home (mise use -g keeps the installed version, mise install X@latest upgrades). Read the bestia launchers and the npm Grok bootstrap. Checked live snapshots and traces on all three machines, and ran the three downgrade-and-watch tests above.

Implemented by Grok 4.7 (worker) and coordinated by Claude Opus 5.5, in Claude Code inside T3 Code.

🤖 Generated with Claude Code

@lukemaj

lukemaj commented Oct 14, 2026

Copy link
Copy Markdown
Contributor Author

Independent review requested on exact head 8ce4b9a0ec92b56b07b5bf268d670ffb74ee35c7: one GPT-6.1 Sol reviewer (review/independent-sol) and one Grok 4.7 reviewer (review/independent-grok). Each posts findings here, then its status.

@github-actions github-actions Bot added vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. size:L labels Oct 14, 2026
@github-actions

github-actions Bot commented Oct 14, 2026 •

Copy link
Copy Markdown
Contributor

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ The exact PR base did not have a successful artifact. Baseline uses the latest successful main measurement shown below.

Provider Metric Main baseline This PR Impact PR ceiling
Codex Total thread wire 5.0 KiB 5.0 KiB 0 B (0.0%) 6.8 KiB ✅
Codex Thread snapshot wire 3.8 KiB 3.8 KiB 0 B (0.0%) 4.9 KiB ✅
Codex Live turn WebSocket wire 1.2 KiB 1.2 KiB 0 B (0.0%) 2.0 KiB ✅
Codex Live turn WebSocket decoded 20.9 KiB 20.9 KiB 0 B (0.0%) 29.3 KiB ✅
Codex Live turn messages 2 2 0 (0.0%) 8 ✅
Claude Total thread wire 5.0 KiB 5.0 KiB 0 B (0.0%) 6.8 KiB ✅
Claude Thread snapshot wire 3.8 KiB 3.8 KiB 0 B (0.0%) 4.9 KiB ✅
Claude Live turn WebSocket wire 1.2 KiB 1.2 KiB 0 B (0.0%) 2.0 KiB ✅
Claude Live turn WebSocket decoded 21.2 KiB 21.2 KiB 0 B (0.0%) 29.3 KiB ✅
Claude Live turn messages 2 2 0 (0.0%) 8 ✅

Baseline: 6d167d4 · PR result: be1a1e7 · Source CI: failure

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

  • Codex decoded thread snapshot: 108.5 KiB
  • Claude decoded thread snapshot: 108.8 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

@lukemaj

lukemaj commented Oct 14, 2026

Copy link
Copy Markdown
Contributor Author

Independent review (GPT-6.1 Sol) of 8ce4b9a

What: Two blocking resolver findings remain at exact head 8ce4b9a0ec92b56b07b5bf268d670ffb74ee35c7.
Why: The native shortcut misses Homebrew mise shims, and the widened script heuristic treats comments as install ownership.
So what: The implementation owner should fix these two cases and add focused regressions before requesting review of the replacement head.

Findings

  1. Blocking: a native-location Homebrew mise shim still gets the native updater. apps/server/src/provider/providerMaintenance.ts:433

    A supported mise shim layout is ~/.local/bin/claude -> /opt/homebrew/Cellar/mise/<version>/bin/mise, either by configuring the shim directory to ~/.local/bin or linking a standard shim there. Mise documents Unix shims as links to its own binary, and allows a shared shim directory such as ~/.local/bin.

    The resolved path passes Claude's native predicate. Neither path contains /mise/installs/ or /mise/shims/, and the mise executable is not a small launcher script. This returns native at line 439 before the isMiseKeg check at line 523. The result is ~/.local/bin/claude update with lock key claudeAgent-native, so Chromeria invokes Claude's self-updater through mise rather than leaving the mise-owned install manual-only. The extraction recognizes the same keg as mise later, but cannot reach that check.

    Evidence: I executed the actual exported resolver at this SHA with the real Claude predicate, a virtual filesystem reporting a 30,000-byte binary, resolved path /review/.local/bin/claude, and real path /opt/homebrew/Cellar/mise/2026.10.4/bin/mise. It returned {"executable":"/review/.local/bin/claude","args":["update"],"lockKey":"claudeAgent-native"}. No updater was spawned. The new link tests cover mise/installs, not a link into the mise keg. Include the existing mise-keg exclusion in the native shortcut and cover this layout. This omission is also present in the upstream #19157 port; port fidelity does not clear it.

  2. Blocking: mentioning “mise where” in a comment disables a native install's updater. apps/server/src/provider/providerMaintenance.ts:613

    The regex scans the entire script without distinguishing executable code from comments or quoted text. For example, this working ~/.local/bin/claude launcher delegates directly to a native Claude binary, not mise:

    #!/bin/sh
    # Previous setup used mise where claude.
    exec "$HOME/.local/share/claude/versions/2.1.299" "$@"

    The added where alternative makes it fail the native shortcut and return manual-only at line 526. The same launcher without the comment returns claude update. This is a newly widened false positive that can leave a native provider stale and remove its one-click update action. A shell comment is not proof that mise owns the provider.

    Evidence: I ran both exact script inputs through the actual resolver using an in-memory filesystem. With the comment: update: null. Without it: native update, lock key claudeAgent-native. Both use the identical native executable path. Restrict detection to the relevant delegation shape and add a negative regression alongside the positive where|which fixtures. I did not observe this wrapper on a live host; this is a confirmed reachable input regression.

Checked and cleared

  • Read the complete PR body, Provider auto-update runs self-updaters that leave the running Claude and Grok stale #263 and its corrective comments, the full fork diff, and the full diffs of upstream #18772 and #19157. The Homebrew extraction and Grok cask branch faithfully port #18772; the native gate faithfully ports #19157. The fork's where|which expansion is the substantive extra behavior.
  • The verified grok-build cask uses the owning brew, upgrade --cask grok-build, the Homebrew lock, and the cask version with its build suffix stripped. An unverified prefix or no brew returns manual-only. npm Grok under a Homebrew Node keg keeps its own updater.
  • Claude's tested mise x, exec-by-mise where, and exec-by-mise which launchers and links into mise installs return manual-only. Rocky's native Claude symlink retains its own updater. Standard shim paths containing /mise/shims/ are excluded; finding 1 is the native-location alias that hides that segment after realpath.
  • Codex/OpenCode/Pi package-manager precedence, npm-before-Homebrew ordering, Homebrew fallback behavior, and updater arguments are preserved by the extraction. Their wrapper detection inherits finding 2.
  • Grok deliberately bypasses the shared mise detector. Provider auto-update runs self-updaters that leave the running Claude and Grok stale #263's corrective comment supersedes the original blanket “mise Grok is stale” claim for bestia's actual npm bootstrap. I independently read the published 1.0.46 bootstrap, which chooses GROK_HOME/bin/grok first. This does not prove every npm install uses that bootstrap: the published postinstall can replace the entry with a sibling native binary for npm on Unix. The new Node-keg fixture tests resolver selection, not launcher/update integration.

Verification and limits

  • Ran the authorized focused command in the specified worktree: npx -y pnpm@11.10.0 exec vp test run apps/server/src/provider/Drivers/GrokDriver.test.ts apps/server/src/provider/providerMaintenance.test.ts: 2 files, 47 tests passed.
  • The discriminating probes imported the actual candidate resolver with mocked filesystem observations and real Effect services. They ran entirely in memory; no fixture file or server was created and no provider updater ran.
  • Read base 54fb0fc1886d7ee1ef030a6e5dae419d2b263a1f directly with git show. Its unconditional native return explains why the six new mise-native cases fail for the intended reason; its old Grok resolver explains why the three cask cases fail. The native Claude and Node-keg preservation cases are expected to pass before and after. I did not execute the new tests against the base, because the authorized worktree must remain at the candidate and unchanged. This is source-level baseline analysis, not an independently rerun red/green cycle.
  • No live host verification, deploy, restart, server, or browser was performed. The deployment acceptance check remains open. The worktree remained clean at the exact requested SHA.

Reviewed independently by GPT-6.1 Sol in the Codex harness inside T3 Code; I did not author this change.

@lukemaj

lukemaj commented Oct 14, 2026

Copy link
Copy Markdown
Contributor Author

Head is now c9339f0, which fixes both blocking findings from the Sol review (mise keg shim at a native path; commented mise where), with regressions. New independent review round requested on c9339f0 from GPT-6.1 Sol (review/independent-sol) and Grok 4.7 (review/independent-grok).

@lukemaj

lukemaj commented Oct 14, 2026

Copy link
Copy Markdown
Contributor Author

Independent review round 2 (GPT-6.1 Sol) of c9339f0

What: Two blocking script-classification findings remain at exact head c9339f0b62c606515f7e95a8ac5b33b200e520cf.
Why: Filtering lines by their first non-whitespace character neither removes all shell comments nor preserves executable substitutions inside heredocs.
So what: The implementation owner should correct these classifications and add discriminating regressions before review of a replacement head.

Findings

  1. Blocking: inline comments and quoted heredoc data still disable a native install's updater. apps/server/src/provider/providerMaintenance.ts:622

    This native launcher has no mise-owned execution path:

    #!/bin/sh
    exec "$HOME/.local/share/claude/versions/2.1.299" "$@" # Previous setup used mise where claude.

    The line survives the new filter, and the regex matches its comment. The actual exported resolver returns update: null; removing only the inline comment returns the native update action with lock key claudeAgent-native. The same false positive occurs for this quoted, non-expanding heredoc:

    #!/bin/sh
    cat >&2 <<'NOTE'
    # Upgrade instructions:
    Previous setup used mise where claude.
    NOTE
    exec "$HOME/.local/share/claude/versions/2.1.299" "$@"

    A textual mention is still being used as install-ownership evidence. This disables the one-click and automatic update paths for a reachable native launcher. Prior finding 2 is therefore partially fixed, not cleared: full-line comments now pass, but inline comments and quoted data reproduce the same underlying false positive. Add negative regressions for both forms and distinguish executable mise delegation from comment/data text. These are confirmed input cases, not claims that these wrappers exist on a live host.

  2. Blocking: the new comment filter removes executable mise substitutions inside an expanding heredoc. apps/server/src/provider/providerMaintenance.ts:620

    This valid wrapper gets its provider path from mise, prefixes it with a marker, and strips that marker before execution:

    #!/bin/sh
    provider=$(cat <<EOF
    #$(mise which claude)
    EOF
    )
    exec "${provider#\#}" "$@"

    Inside an unquoted heredoc, # is data, and $(mise which claude) executes. Line 620 removes that whole line, so the native shortcut at lines 436-443 now accepts the wrapper. The actual resolver returns {"command":"/review/.local/bin/claude update","executable":"/review/.local/bin/claude","args":["update"],"lockKey":"claudeAgent-native"} instead of manual-only. Chromeria consequently invokes the self-updater through a mise-owned launcher, reintroducing the ownership error this PR is intended to prevent.

    Evidence: The resolver probe used an in-memory filesystem and the real exported resolver. I separately ran this exact shell shape entirely through stdin with mise stubbed to return /usr/bin/printf; it executed that harmless selected target, printed mise-selected-target, and exited 0. No provider updater ran. The prior head's unfiltered regex detects this input; the new line removal is the source of the regression. Add a regression that preserves command substitution within heredoc data rather than assuming every trimmed # starts a shell comment.

Disposition of prior findings

  • Prior finding 1, Homebrew mise-keg shim: fixed. The new native guard at providerMaintenance.ts:439 excludes the real mise keg before returning native capabilities. The new regression at providerMaintenance.test.ts:625 passed. An independent in-memory probe of /review/.local/bin/claude -> /opt/homebrew/Cellar/mise/2026.10.4/bin/mise, with a 30,000-byte binary, returned manual-only without spawning anything.
  • Prior finding 2, comment mentions: partially fixed, remains blocking as finding 1. The new full-line-comment regression at providerMaintenance.test.ts:646 passed. Independent plain and indented full-line-comment probes retained the native updater. Inline comments and quoted heredoc content did not.

Whole-PR review and proof

  • Read the operations Skill, code-review procedure, review-method and impact-analysis references, and verification reference in full. Read the complete prior-round comment, PR body, Provider auto-update runs self-updaters that leave the running Claude and Grok stale #263 body and comments, git show c9339f0, and the entire PR diff against base 54fb0fc1886d7ee1ef030a6e5dae419d2b263a1f.
  • Read the complete current upstream diffs of fix(grok): a Homebrew-installed Grok updates through brew and is compared against the cask pingdotgg/t3code#18772 and #19157. The Homebrew extraction, Grok cask branch, and original native mise gate preserve the ported behavior after module-path adaptation. The additional where|which detection and this round's keg/comment fixes are fork changes. Upstream #19157 also adds a credits file, which is absent here; no functional port defect follows from that omission.
  • Rechecked package-manager precedence and shared resolver consumers: native Claude preservation, npm-before-Homebrew ordering, cask prefix verification, unavailable-brew manual fallback for Grok, cask build-suffix stripping, and npm Grok inside a Homebrew Node keg. No additional supported finding in those paths. Grok's continued own updater for npm/mise-npm follows Provider auto-update runs self-updaters that leave the running Claude and Grok stale #263's corrective comments; this is resolver review, not a new live bootstrap/update integration proof.
  • Ran exactly npx -y pnpm@11.10.0 exec vp test run apps/server/src/provider/Drivers/GrokDriver.test.ts apps/server/src/provider/providerMaintenance.test.ts: 2 files, 49 tests passed at the requested head, including both new regressions.
  • In-memory probes imported the actual exported resolver and supplied filesystem observations with the same native predicate as ClaudeDriver. Native, plain/indented full-line-comment, and CRLF native-comment inputs retained claude update; mise where and CRLF mise which inputs stayed manual-only. CRLF probes establish detection behavior, not POSIX executable compatibility.
  • The heredoc false-negative baseline comparison is source/regex analysis, not an executed old-head test suite. No checkout, reset, tracked edit, server, browser, deployment, or live-state access occurred. Final worktree status was clean and HEAD remained c9339f0b62c606515f7e95a8ac5b33b200e520cf. Live deployment acceptance remains outside this review.

Elon record

Requirements and who asked: The user requested exact-head round 2 independent review, verification of both prior findings, shell-edge regression checks, upstream comparison, and focused tests.
Deleted: Repository edits, deployment, servers, broad checks, and additional reviewers are unnecessary for this authorized review.
Bottleneck: Whether script text proves mise ownership before the native updater is selected.
Checked myself: Full candidate/upstream diffs, actual resolver probes, shell expansion semantics with a harmless target, and all 49 focused tests.

Verdict: failure on c9339f0. Independently reviewed by GPT-6.1 Sol in the Codex harness inside T3 Code; I did not author this change.

@lukemaj

lukemaj commented Oct 14, 2026

Copy link
Copy Markdown
Contributor Author

Head is now 38d1c10. Sol round 2's two findings were both in the fork's mise where|which launcher heuristic. That heuristic is removed, so launcher detection is upstream's mise x|exec check unchanged from main. The Homebrew mise-keg fix from round 1 stays. Review round 3 requested on 38d1c10 from GPT-6.1 Sol and Grok 4.7.

@lukemaj

lukemaj commented Oct 14, 2026

Copy link
Copy Markdown
Contributor Author

Independent review round 3 (GPT-6.1 Sol) of 38d1c10

What: No blocking or non-blocking code finding remains in the inspected scope at exact head 38d1c10fe3e8848b00b7a651e4def75900237568.
Why: The Homebrew mise-keg guard is retained, while the added where|which heuristic and line filter responsible for the remaining prior findings are removed.
So what: Independent code review succeeds on this SHA; deployment and the outstanding live acceptance check remain the implementation owner's next steps under their delivery authority.

Findings

None. This verdict concerns regressions introduced or worsened by this PR, against base 54fb0fc1886d7ee1ef030a6e5dae419d2b263a1f; it does not claim the inherited launcher heuristic identifies every possible shell program.

Disposition of each prior finding

  1. Round 1 finding 1: fixed, no longer blocking. At apps/server/src/provider/providerMaintenance.ts:439, the native shortcut excludes a real path inside the Homebrew mise formula keg before returning native capabilities. The focused regression at apps/server/src/provider/providerMaintenance.test.ts:587 exercises ~/.local/bin/claude -> <prefix>/Cellar/mise/<version>/bin/mise and passed. The later mise branch also retains this exclusion. The real native Claude symlink preservation test passed.
  2. Round 1 finding 2: cleared by removal, no longer blocking. At apps/server/src/provider/providerMaintenance.ts:619, mise where and mise which no longer match the classifier. The previous full-line comment input therefore cannot cause the native shortcut to be rejected by this heuristic. I evaluated the candidate's actual return expression against that input and obtained false, and traced the native return at lines 435-442.
  3. Round 2 finding 1: cleared by removal, no longer blocking. At the same providerMaintenance.ts:619 expression, the previously reported inline comment and quoted-heredoc inputs containing mise where both return false. Those added false positives no longer suppress the native updater. This does not extend the finding to inherited mise x|exec textual sensitivity, which was not changed by this PR.
  4. Round 2 finding 2: introduced filter removed; no longer blocking for this PR. At providerMaintenance.ts:613-619, the script is read intact and the #-line filter is gone. The prior expanding heredoc containing #$(mise which claude) still returns false, because support for which was also removed. This is the same behavior as the base, rather than a newly introduced false negative. The native-looking exec-by-path launcher remains outside the inherited detector's coverage. The review brief explicitly confirms that the host launchers requiring that extra detection were retired; I did not independently inspect or change that host.

Whole-PR review and evidence

  • Read the AgentsMD operations Skill, code-review procedure, verification reference, review-method, impact-analysis, and structure-and-constraints references in full before reviewing. Read both prior review comments in full, the current PR description, Provider auto-update runs self-updaters that leave the running Claude and Grok stale #263 body and all returned comments, the complete PR diff, and complete upstream diffs for fix(grok): a Homebrew-installed Grok updates through brew and is compared against the cask pingdotgg/t3code#18772 and #19157.
  • Independently compared the complete isMiseWrapperScript block with origin/main through git show: byte-for-byte equal. An in-memory Node probe evaluated the actual candidate return expression: prior full-line comment, inline comment, quoted heredoc, and expanding heredoc inputs all returned false; mise x and mise exec positive inputs returned true. These are classifier-expression checks plus source tracing, not executions of the full resolver or shell launchers.
  • Rechecked the surrounding shared resolver and Claude, Codex, OpenCode, and Pi consumers, plus Grok's maintenance resolution and update runner. The Homebrew extraction preserves npm-before-Homebrew precedence and prior fallback behavior. Grok's cask branch uses the verified owning brew, upgrade --cask, the Homebrew lock, and cask version with build suffix stripped; unavailable or mismatched brew returns manual-only. Non-cask Grok retains its existing updater and instance environment, including npm inside a Homebrew Node keg. Cursor and Antigravity have no changed shared-resolver path. This server-side change requires no client or wire-contract change.
  • The functional ports match upstream after module-path adaptation. The retained extra native guard closes the mise-keg shortcut gap missed by #19157. The fork ownership manifest and edit allowlist cover the four changed upstream files.
  • Ran exactly npx -y pnpm@11.10.0 exec vp test run apps/server/src/provider/Drivers/GrokDriver.test.ts apps/server/src/provider/providerMaintenance.test.ts in the specified worktree: 2 files passed, 45 tests passed, exit 0. This includes cask ownership/fallback, native mise paths, the mise-keg regression, native Claude preservation, and Node-keg npm Grok preservation.
  • Final local HEAD and live PR head both remained 38d1c10fe3e8848b00b7a651e4def75900237568; git status --short was empty. No checkout, reset, tracked edit, server, browser, deployment, or live-state access occurred. The focused tests are not a complete CI or deployment gate. I did not rerun baseline tests, lint, typecheck, or live updater integration; earlier reported results are not presented as my proof.

Elon record

Requirements and who asked: The user requested independent round 3 review of the exact candidate, disposition of every prior finding, upstream comparison, focused tests, one PR comment, and a SHA-bound status.
Deleted: The candidate removes the added where|which heuristic and comment filter; this review needs no implementation edits, servers, deployment, broad checks, or additional reviewers.
Bottleneck: Whether any introduced install-ownership regression remains after the heuristic removal while the mise-keg guard stays.
Checked myself: Full candidate and upstream diffs, prior findings, shared consumers and update runner, exact classifier equality and in-memory expression checks, all 45 focused tests, and final local/live candidate identity.

Verdict: success on 38d1c10fe3e8848b00b7a651e4def75900237568. Independently reviewed by GPT-6.1 Sol in the Codex harness inside T3 Code; I did not author this change.

lukemaj and others added 3 commits October 14, 2026 09:56
…s them

Homebrew grok-build upgrades with brew upgrade --cask. A cask the found brew cannot verify stays manual. Mise launchers and mise install links at native Claude paths stay manual, including exec by mise where or mise which. A real native Claude install still uses claude update.

Co-Authored-By: Grok 4.7 <noreply@x.ai>
A ~/.local/bin/claude symlink into the Homebrew mise keg stays manual-only. A native launcher that only mentions mise inside a shell comment still uses claude update.

Co-Authored-By: Grok 4.7 <noreply@x.ai>
isMiseWrapperScript again matches only mise x or mise exec on the whole script, the same check as upstream #19157. The Homebrew mise-keg native-shortcut guard stays.

Co-Authored-By: Grok 4.7 <noreply@x.ai>
@lukemaj
lukemaj force-pushed the fix/263-provider-update-owners branch from 38d1c10 to be1a1e7 Compare October 14, 2026 07:57
@lukemaj

lukemaj commented Oct 14, 2026

Copy link
Copy Markdown
Contributor Author

Rebased onto main a68e394 because #275 conflicted in docs/fork-features.md: both sides added an issue link, and the merge keeps #266 and #263. Head is now be1a1e7. The code diff is byte-identical to 38d1c10, and 45 focused tests and tsc pass. Round 4 is requested on be1a1e7: a full Grok 4.7 review, and a Sol check of the rebase (Sol passed 38d1c10).

@lukemaj

lukemaj commented Oct 14, 2026

Copy link
Copy Markdown
Contributor Author

Independent review round 4 (GPT-6.1 Sol) of be1a1e7

What: No blocking or non-blocking finding in the requested rebase review of exact head be1a1e7ec8020b480239b6c2e2b6a154fcd01285.
Why: The provider changes are identical to round 3, the documentation merge preserves both branches, and the two new main commits introduce no conflicting resolver behavior.
So what: Independent review succeeds on this SHA; the implementation owner retains responsibility for remaining acceptance and delivery gates.

Findings

None in the inspected scope.

Rebase evidence

  • Read AgentsMD operations, its code-review procedure and verification reference, and the linked review-method and impact-analysis references in full. Read the round 3 review comment 6163553971. This round verifies the rebase rather than repeating the full prior review.
  • Ran git range-diff 54fb0fc..38d1c10 a68e394..be1a1e7. The second and third commits are equal; the first differs only in the documentation conflict resolution.
  • Ran diff <(git diff 54fb0fc 38d1c10) <(git diff a68e394 be1a1e7). Differences are confined to documentation context/issue-list merging and the allowlist index hash. The provider-only diff comparison produces no output, and git diff --quiet 38d1c10 be1a1e7 -- apps/server/src/provider exits 0. Both the code patches and final provider tree are identical.
  • Parsed the feature-map JSON in memory. The provider-auto-update issues, newFiles, and upstreamFiles are exact duplicate-free unions of the prior candidate and new main, retaining Opt-in automatic provider updates per environment #159, Move provider update settings to Providers → Advanced #266, and Provider auto-update runs self-updaters that leave the running Claude and Grok stale #263. The edit allowlist retains main's ProviderSettingsPanel entry and adds exactly the four intended provider files, with no removals.

Interaction checks and proof

  • Inspected main's fix(server): release a ContextMD reservation the OpenCode plugin drops #274 ContextMD service/route/state changes. Its reservation release operates on ContextMD delivery state, with no changed provider resolver, update runner, or wire contracts.
  • Inspected Move provider update settings to Providers, Advanced #275's settings relocation and search changes. The moved rows retain enableProviderUpdateChecks and autoUpdateProviders with the same scoped settings writer. Traced the unchanged automatic updater's settings gates and maintenance-capability lookup, the update runner's authoritative resolver lookup, and Grok's cached maintenance resolution. The UI relocation does not bypass the corrected ownership resolver.
  • The only shared changed files between main's two commits and this PR are docs/fork-features.md and scripts/fork-upstream-edits.txt; neither range changes packages/contracts.
  • Ran exactly npx -y pnpm@11.10.0 exec vp test run apps/server/src/provider/Drivers/GrokDriver.test.ts apps/server/src/provider/providerMaintenance.test.ts in the specified worktree: 2 test files passed, 45 tests passed, exit 0.
  • Final local HEAD and live PR head both equal the requested SHA; live base is a68e39462f10c027d79f256856d082dc967a5676. The worktree remains clean. No source edits, checkout/switch/reset/pull/commit, server, browser, or live userdata access occurred. Focused tests are not a complete CI or live updater acceptance gate.

Elon record

Requirements and who asked: The user requested exact-SHA rebase verification, interaction checks, focused tests, one PR comment, and a SHA-bound status.
Deleted: No repeated whole-PR review, implementation edits, broad checks, servers, or additional agents.
Bottleneck: Whether rebasing onto #274 and #275 changed the approved provider behavior or lost either side of the documentation merge.
Checked myself: Range-diff, complete patch comparison, provider tree equality, merged feature-map/allowlist contents, relevant new main code and update consumers, all 45 focused tests, and final local/live identity.

Verdict: success on be1a1e7ec8020b480239b6c2e2b6a154fcd01285. Independently reviewed by GPT-6.1 Sol, medium effort, in the Codex harness inside T3 Code; I did not author this change.

@lukemaj

lukemaj commented Oct 14, 2026

Copy link
Copy Markdown
Contributor Author

Independent review (Grok 4.7) of be1a1e7

What: No blocking or non-blocking finding remains in the inspected scope at exact head be1a1e7ec8020b480239b6c2e2b6a154fcd01285.
Why: The provider resolver is unchanged from the reviewed tree 38d1c10, and each checked install still gets the updater that owns it.
So what: Independent review succeeds on this SHA. Deploy and the open bestia boot-log check stay with the implementation owner.

Findings

None. This verdict covers what this PR introduces or worsens against base a68e39462f10c027d79f256856d082dc967a5676. The inherited mise x|exec text match is unchanged and out of scope.

Checked

  • git diff 38d1c10fe3e8848b00b7a651e4def75900237568 HEAD is empty for GrokDriver.ts, GrokDriver.test.ts, providerMaintenance.ts, and providerMaintenance.test.ts. The rebase onto a68e394 kept issue 266 and added issue 263 in docs/fork-features.md. The four provider files are on the allowlist and in that feature's upstreamFiles.
  • Native shortcut at apps/server/src/provider/providerMaintenance.ts:435 returns the provider updater only when a native path matches, neither path is a mise install or shim (:261), the real path is not the Homebrew mise keg (:439, :541), and the file is not a mise x|exec launcher (:616). Otherwise a mise path, keg, or launcher returns manual at :524.
  • mise x launcher: providerMaintenance.test.ts:497 expects no update. A ~/.local/bin link into mise/installs (:516, Claude at :543) is manual because the real path contains /mise/installs/. A link onto Cellar/mise/<version>/bin/mise (:587) is manual because of the keg guard, which the native shortcut used to skip. The launcher body is the same as origin/main; upstream #19157's native gate is that check plus this fork's keg line.
  • Native Claude ~/.local/bin/claude to ~/.local/share/claude/versions/<version> stays claude update with lock key claudeAgent-native (providerMaintenance.test.ts:563). The test predicate matches ClaudeDriver.ts:78.
  • Verified grok-build cask (GrokDriver.ts:73, test :114) runs <prefix>/bin/brew upgrade --cask grok-build, lock key homebrew, and compares 1.2.4 after dropping the cask build suffix. A foreign prefix (:169) and no brew (:209) stay manual, so grok update does not write a second copy. The Grok resolver matches upstream #18772 aside from import paths. The Homebrew extraction matches that PR: a missing brew or a prefix mismatch returns null, and the shared caller still applies the old fallback (providerMaintenance.ts:532).
  • npm Grok inside Cellar/node/<version>/lib/node_modules is a formula, not a cask, so it keeps grok update and does not spawn brew (GrokDriver.test.ts:243).
  • Codex standalone (CodexDriver.ts:83), OpenCode ~/.opencode/bin (OpenCodeDriver.ts:82), and Pi (PiDriver.ts:53, no native path predicate) are not in the diff. The extraction does not change their precedence: native paths still return before Homebrew, and Pi still reaches Homebrew only after the package-manager checks, then its own updater.

Proof

npx -y pnpm@11.10.0 exec vp test run apps/server/src/provider/Drivers/GrokDriver.test.ts apps/server/src/provider/providerMaintenance.test.ts in the worktree: 2 files passed, 45 tests passed, exit 0. HEAD stayed be1a1e7ec8020b480239b6c2e2b6a154fcd01285 and git status --porcelain was empty. No checkout, server, deploy, or live updater run. The focused tests are not the full CI gate.

Elon record

Requirements and who asked: The user asked for an independent review of exact head be1a1e7, the listed install layouts, focused tests, one PR comment, and status review/independent-grok.
Deleted: Code edits, deploy, extra test suites, and judging the inherited mise x|exec text limits.
Bottleneck: Whether the rebase or the resolver still selects an updater that does not own the binary.
Checked myself: PR and upstream diffs, the resolver and the four drivers, file identity against 38d1c10, and all 45 focused tests.

Verdict: success on be1a1e7ec8020b480239b6c2e2b6a154fcd01285. Independently reviewed by Grok 4.7. I did not author this change.

@lukemaj

lukemaj commented Oct 14, 2026

Copy link
Copy Markdown
Contributor Author

CI on be1a1e7: 21 pass. Test Server 6 fails in src/mcp/OrchestratorMcpToolkit.integration.test.ts ("delegates cross-provider tasks…": expected 1 continuation offer, got 2), and Check only aggregates that job. The same test fails identically on main a68e394 (CI run 38531256583), so the failure is pre-existing and tracked in #259. This PR doesn't touch MCP or orchestration. Independent reviews on be1a1e7: review/independent-sol success, review/independent-grok success. Agent cost: agent-observer publish reported "no sessions in scope", so no cost comment was posted.

@lukemaj
lukemaj merged commit 51ab123 into main Oct 14, 2026
27 of 29 checks passed
@lukemaj
lukemaj deleted the fix/263-provider-update-owners branch October 14, 2026 08:09
lukemaj added a commit that referenced this pull request Oct 14, 2026
…s them (#272)

* fix(server): update Claude and Grok only through the install that owns them

Homebrew grok-build upgrades with brew upgrade --cask. A cask the found brew cannot verify stays manual. Mise launchers and mise install links at native Claude paths stay manual, including exec by mise where or mise which. A real native Claude install still uses claude update.

Co-Authored-By: Grok 4.7 <noreply@x.ai>

* fix(server): ignore mise keg shims and commented mise mentions

A ~/.local/bin/claude symlink into the Homebrew mise keg stays manual-only. A native launcher that only mentions mise inside a shell comment still uses claude update.

Co-Authored-By: Grok 4.7 <noreply@x.ai>

* fix(server): drop the fork's mise where/which launcher heuristic

isMiseWrapperScript again matches only mise x or mise exec on the whole script, the same check as upstream #19157. The Homebrew mise-keg native-shortcut guard stays.

Co-Authored-By: Grok 4.7 <noreply@x.ai>

---------

Co-authored-by: Grok 4.7 <noreply@x.ai>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size:L vouch:trusted PR author is trusted by repo permissions or the VOUCHED list.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant