feat(update): surface update-available notices on startup

[Vasanthdev2004]

Summary

• surface an explicit update-available notice in the footer when a newer version exists
• extend updater result state so the UI can distinguish update_available and up_to_date from install outcomes
• reuse the structured updater result for package-manager installs so users get a consistent startup notice and next-step command

Why

Issue #533 points at a real UX gap: users can feel like OpenClaude does not suggest newer versions on startup, even though update logic already exists. This change focuses on surfacing update availability more clearly rather than introducing silent auto-install behavior.

Scope

• src/utils/autoUpdater.ts
• src/components/AutoUpdater.tsx
• src/components/PackageManagerAutoUpdater.tsx

Notes

• Draft on purpose, so we can still polish behavior across install paths and follow up with focused validation once a full local test environment is available.
• This is intentionally a notification/UX improvement, not a silent self-update change.

Closes #533

[Vasanthdev2004]

Quick current-head summary after the follow-up fixes on this draft:

What changed in this PR now:

• added an explicit startup update_available notice path for the general updater footer
• added the missing native-install update_available notice path in src/components/NativeAutoUpdater.tsx
• kept openclaude update as a real update command instead of regressing it into a notice-only no-op
• removed bad upstream-facing suggestions like winget upgrade Anthropic.ClaudeCode
• fixed invalid guidance like openclaude doctor:runtime to the real openclaude doctor command
• avoided telling package-manager installs to switch to npm, and instead keep that path generic/safe

Files touched across the follow-ups:

• src/components/AutoUpdater.tsx
• src/components/PackageManagerAutoUpdater.tsx
• src/components/NativeAutoUpdater.tsx
• src/utils/autoUpdater.ts
• src/cli/update.ts

Intent here is still the same: solve #533 by surfacing update availability on startup more reliably, while cleaning the updater UX toward OpenClaude-specific guidance and avoiding the earlier regressions.

[Vasanthdev2004]

[kevincodex1]

I like this direction on this, can we fix the update available notification? I'm seeing a dummy versions like 99.0.0 and also can wehave a command /update-self ?

[Vasanthdev2004]

@kevincodex1 Yep, 99.0.0 is just the local test stub value, not the real version users would see from an actual update check.

I agree the notification should be cleaned up so test/dummy values don’t leak into the visible UX.

On /update-self, that also makes sense as a nicer entrypoint for users. Right now the underlying command path is openclaude update, but I’m good with a follow-up that adds a dedicated slash command if we want the update flow discoverable in-app.

[kevincodex1]

yeah I think we can have that / command for updating .

[kevincodex1]

looks good to me

[kevincodex1]

@Vasanthdev2004 please fix conflicts bro

[Vasanthdev2004]

done @kevincodex1

[kevincodex1]

looks great to me !

[kevincodex1]

one more eyes here bro when you have time @gnanam1990 @auriti

[FluxLuFFy]

@kali113 can you take a look ?

[kali113]

@FluxLuFFy i don't have contributor flag 😭 but I will review the pr

[kevincodex1]

thanks @kali113

[kali113]

Hi! I've been reviewing this PR and wanted to share some feedback. Overall I really like the update notification feature - it's super helpful to see when updates are available right on startup! 👍

I did notice a few things that might need some attention though:

1. Package manager messages: The current messaging is a bit vague (like "run the Homebrew command for your OpenClaude formula"). It would be more user-friendly to show the actual copy-pasteable command like before ( or whatever the correct command is).

2. State management: The logic in PackageManagerAutoUpdater.tsx where it sets when it sees seems like it might clear the notification immediately? I could be wrong but wanted to flag it in case it's a bug.

3. Comments: A lot of helpful comments explaining why things work were removed. Those were really useful for understanding the code - maybe we could keep those? 😅

4. Testing: Would be great to have some tests for the new states, especially since there are some edge cases with the version checking.

Also just a heads up - I noticed some hardcoded checks like which would always be false, might want to use instead.

The rebranding from Claude Code to OpenClaude looks really consistent though - nice work on that! And the development build message with the git commands is much clearer now.

Thanks for all your hard work on this! Let me know if any of these points need clarification.

~ kali113

[kali113]

Quick follow-up to my previous comment (which had some formatting issues) - here are the technical details:

Critical issues found:

1. Hardcoded environment checks - Found several places using "production" === "test" which is always false. Should use process.env.NODE_ENV instead.

2. PackageManagerAutoUpdater state bug - The else-if branch that sets status: 'up_to_date' when seeing 'update_available' will immediately clear update notifications before users can see them.

3. Stale closure in compiled JSX - The checkForUpdates callback is memoized but never invalidates when autoUpdaterResult/onAutoUpdaterResult props change.

4. Missing tests - No test coverage for the new update_available and up_to_date states.

5. Vague package manager messages - Users no longer get copy-pasteable commands like before.

Happy to provide more details on any of these!

[kevincodex1]

@Vasanthdev2004 please address @kali113 comments

[FluxLuFFy]

Thanks @kali113 I am planning to add some new features / bugs fixes soon hope you will help me catch bugs and issues

[FluxLuFFy]

@Vasanthdev2004 fix it bro

[Vasanthdev2004]

Thanks for the careful review, @kali113. I pushed a follow-up pass that addresses the concrete updater concerns on this PR head:

• replaced the brittle test/dev env guard with a normal process.env.NODE_ENV check in AutoUpdater
• simplified PackageManagerAutoUpdater state flow so the update notice is driven by actual current update state instead of the older awkward branch shape
• restored copy-pasteable package-manager commands where we can (brew, winget, apk) instead of only generic wording
• added focused test coverage for the package-manager update_available / up_to_date notice paths

I did not restore every removed comment wholesale, but I did try to make the updated logic clearer in the code itself and cover the important state transitions with tests.

If you want, I can also do a small follow-up just for /update-self separately so we keep this PR scoped to the startup notice behavior.