feat: auto install latest versions #533

[Syntax-Error-1337]

Summary

• What changed:

  • Implemented a non-blocking startup check (notifyUpdates) in a new utility src/utils/updateNotifier.ts that queries npm for the latest @gitlawb/openclaude version and suggests an update if available.
  • Fixed version comparison logic in src/cli/update.ts, AutoUpdater.tsx, NativeAutoUpdater.tsx, and PackageManagerAutoUpdater.tsx to use MACRO.DISPLAY_VERSION (the actual version) instead of the build-time mock MACRO.VERSION (99.0.0).
  • Modified the claude update CLI to allow updates for the Open Claude package even when running with third-party providers.
  • Updated LogoV2.tsx, Config.tsx, and useUpdateNotification.ts to sync release notes tracking and version-based settings with the actual display version.

• Why it changed:

  • In Open Claude, MACRO.VERSION is set to 99.0.0 to prevent upstream Anthropic kill-switches from disabling the tool. However, this caused Open Claude's own update mechanisms to fail as they always perceived the local version as "newer" than the latest release on npm.
  • Users were missing important updates because the CLI didn't suggest installing newer versions of the fork.

Impact

• User-facing impact:

  • Users will now receive a green notification in the terminal on startup when a newer version of Open Claude is available.
  • The claude update command now correctly identifies and installs newer versions for fork users.
  • Release notes and version-specific settings (like channel downgrades) now reflect the true version number.

• Developer/maintainer impact:

  • Improved update reliability for fork users while maintaining the "99.0.0" bypass for upstream compatibility.
  • Standardized version checking across the codebase by prioritizing DISPLAY_VERSION.

Testing

• bun run build - Successfully bundled the CLI.
• bun run smoke - Verified --version output is correct (0.1.8 (Open Claude)).
• bun test - All 616 tests passed.
• Manual verification: Confirmed that mocking a lower DISPLAY_VERSION triggers the update suggestion, while matching the latest version suppresses it.

Notes

• Provider/model path tested: OpenAI and Gemini (verified that the update command is no longer blocked for these providers).
• Screenshots attached (if UI changed): N/A (CLI console output).
• Follow-up work or known limitations: The update suggestion respects NODE_ENV=development and can be disabled via OPENCLAUDE_SKIP_UPDATE_CHECK=true.

[kevincodex1]

@Vasanthdev2004 kindly have a look this might be related on the one you working on

[gnanam1990]

Thanks, I think the DISPLAY_VERSION fix direction is correct, and I agree that OpenClaude should not treat the build-time 99.0.0 bypass as the real user-facing version for update/release-note decisions.

But I’m not comfortable merging the startup notifier as-is.

The blocker for me is that this adds a new outbound update check on normal startup via notifyUpdates() in main.tsx, which calls getLatestVersion(channel) remotely by default. That changes the trust/behavior surface in a way that needs more care than a normal version-compare fix.

Specific concerns:

1. this introduces a new outbound network call during startup
2. it appears to run by default in normal production usage
3. I don’t see throttling / cache-window behavior in the new notifier path
4. this PR mixes two different scopes: fixing display-version comparisons, and adding a startup update-notification network feature

I’d be much more comfortable if this were split so the version-comparison fixes can land independently, and the startup notifier comes back only with a clearer trust story, throttling/caching, and opt-in or well-justified behavior.

[gnanam1990]

@Vasanthdev2004 check once ..

[kevincodex1]

@Syntax-Error-1337 kindly provide screenshot please

[Vasanthdev2004]

Thanks for taking a swing at this. I checked the current head against the existing updater work and I do not think this is merge-ready.

Verdict

Needs changes

Blockers

1. This overlaps heavily with the existing updater-notice work already in progress for the same issue area, but the branch mixes in a separate startup notifier path (src/utils/updateNotifier.ts + main.tsx) that changes behavior and trust surface in a different way. So even before code details, the review surface is redundant-but-divergent rather than a clean focused fix.

2. The PR still carries upstream Claude-specific commands / branding in user-facing update paths. For example, the package-manager update strings and native/error paths in src/cli/update.ts still emit commands like claude update, claude doctor, claude install, brew upgrade claude-code, and winget upgrade Anthropic.ClaudeCode. For OpenClaude, that is not the user-facing command story we want to reinforce.

3. The new startup notifier adds an outbound update check during normal startup via notifyUpdates() in main.tsx, but I do not see enough justification/guarding here to merge that as part of a version-display cleanup. That is a broader behavior change than just fixing the visible 99.0.0 issue.

What looks directionally right

• using DISPLAY_VERSION instead of the build-time placeholder where appropriate is the right direction
• fixing the visible dummy-version problem is a valid UX issue

But in its current shape this is both overlapping with the existing work and still not aligned with OpenClaude-specific updater UX. I would not merge this branch as-is.

[Vasanthdev2004]

One extra note for clarity: this update-notice / startup-update UX area is already being actively worked on in #535, so I would prefer we converge there rather than merge a parallel branch for the same issue theme.

If the main thing you were aiming to fix here is the visible 99.0.0 / display-version problem, that part is a legitimate concern. But I would rather fold any good isolated fix for that into the existing PR than land a competing updater path with different behavior and OpenClaude/upstream command mismatches.

[auriti]

Rechecked the current head with the green smoke-and-tests run.

I still don’t think this is merge-ready, for the same core reasons as the earlier reviews:

1. The PR still mixes two scopes that should not be shipped together.

   • fixing DISPLAY_VERSION / visible version comparisons is one thing
   • adding a new startup notifier (src/utils/updateNotifier.ts + main.tsx) is a separate behavior/trust-surface change

2. The startup notifier is still a real outbound network check on normal startup.
   notifyUpdates() runs from main.tsx and calls getLatestVersion(...) by default. I still don’t see enough throttling/cache-window/justification here to treat that as a small UX cleanup.

3. The updater UX is still not aligned with the OpenClaude-specific path.
   Even after the DISPLAY_VERSION cleanup, this branch still carries upstream-facing package-manager guidance in src/cli/update.ts / src/components/PackageManagerAutoUpdater.tsx (brew upgrade claude-code, winget upgrade Anthropic.ClaudeCode, etc.), which is exactly the command story we should avoid reinforcing in OpenClaude.

So my read is still:

• the version-display fixes are directionally right
• but the startup notifier should be split out, and the updater UX should be aligned with the OpenClaude-specific commands/workflows before merge

I would still keep this at request changes rather than merging it as-is.

[Vasanthdev2004]

Targeted maintainer triage review of the current head ($short).

Verdict: Needs changes

Blocking issue:

1. GitHub reports this branch as DIRTY / conflicting with main, so it cannot be merged or final-approved as-is. Please rebase or merge latest main, resolve the conflicts, and rerun the relevant checks.

I did not do a full code review because the current branch state is not mergeable. Happy to re-review once the branch is clean.

[jatmn]

Closing as stale/abandoned