You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
v2 — Go rewrite (1.x), main-v2 (active development)
What problem does this solve?
First of all, thank you for the incredible work on Reasonix. The prefix-cache-first architecture is genuinely innovative, and it's exciting to see the project grow to 23k+ stars in just a few weeks.
I'd like to respectfully raise a concern that I believe is worth prioritizing: the auto-update experience is fragmented and has several open failure modes across platforms. For a developer tool that users rely on daily and that ships releases every two days, a seamless update path is arguably as important as the core agent loop itself — because if users can't reliably stay on the latest version, they miss critical bug fixes and cache optimizations that the team is shipping at an impressive cadence.
Current state of the updater — a consolidated view
I've gone through the existing issues and PRs tagged updater. Here's the landscape:
Open issues:
[Feature]: 希望mac支持自动更新，而不是每次手动下载安装包替换，太麻烦了 #4777 — macOS users have no in-app auto-update; they must manually download and replace the .app bundle every time. This was filed today by another user.
The developer tooling space has converged on a clear consensus: auto-update is not a "nice-to-have" — it is core infrastructure. A few examples:
VS Code pioneered the "silent background update + apply on restart" model. Its update mechanism is considered a key competitive advantage — users rarely think about versioning because it just works. The team has written extensively about how seamless updates reduce their support burden by keeping the user base on a narrow version band.
Firefox invested heavily in Background Update (Project Balrog) precisely because they found that every manual update step loses ~15-30% of users who simply never get around to it. For a security-sensitive product, that's unacceptable — but for a coding agent that processes your entire codebase, the stakes are arguably comparable.
Homebrew made brew upgrade and brew autoupdate a first-class part of the ecosystem. Their philosophy: the default should be "stay current," with opt-out, not opt-in.
Rust's rustup demonstrates that even CLI-first tools can have a frictionless self-update story. rustup update is a single command that handles toolchain, components, and targets atomically.
Claude Code (a direct competitor) auto-updates on every npm install -g @anthropic-ai/claude-code invocation and nudges users with claude update when a new version is detected. Reasonix's reasonix update exists ([Feature Request] 添加 reasonix update / reasonix upgrade 自更新命令 #3059) but lacks proactive notification.
Suggested priorities
With respect for the team's bandwidth, I'd suggest these as high-impact, incremental steps rather than a single monolithic effort:
Fix the Windows update failure ([Bug]: Update failed after clicking “Check for updates” #4078) — This is a regression-level issue. Users who click "Check for updates" get an error. That's the worst possible UX for an update mechanism: it teaches users not to trust it.
CLI proactive update notification — When reasonix code starts, check if the current version is the latest (a lightweight HEAD to the releases API). If not, show a non-blocking hint: "A new version (vX.Y.Z) is available. Run 'reasonix update' to upgrade." This is what npm, pnpm, yarn, and cargo all do, and it's remarkably effective at keeping users current.
Reasonix has a genuine architectural moat in the cache-first loop. But that moat only protects users who are running the latest version with the latest optimizations. Every user stuck on an old version because the update path was too painful is a user not benefiting from the team's relentless shipping velocity — and potentially filing bugs that have already been fixed.
The team has already done excellent foundational work (#4141 retry/resume, #4742 Authenticode signing, #3280 portable releases). I'd humbly suggest that consolidating these into a cohesive, cross-platform, zero-friction update experience would be one of the highest-leverage investments for the project's next chapter.
Thank you for reading, and again — incredible work on Reasonix. 🙏
Version line
v2 — Go rewrite (1.x), main-v2 (active development)
What problem does this solve?
First of all, thank you for the incredible work on Reasonix. The prefix-cache-first architecture is genuinely innovative, and it's exciting to see the project grow to 23k+ stars in just a few weeks.
I'd like to respectfully raise a concern that I believe is worth prioritizing: the auto-update experience is fragmented and has several open failure modes across platforms. For a developer tool that users rely on daily and that ships releases every two days, a seamless update path is arguably as important as the core agent loop itself — because if users can't reliably stay on the latest version, they miss critical bug fixes and cache optimizations that the team is shipping at an impressive cadence.
Current state of the updater — a consolidated view
I've gone through the existing issues and PRs tagged
updater. Here's the landscape:Open issues:
.appbundle every time. This was filed today by another user.Update failed: mcp config .mcp.json: invalid character '}' looking for beginning of object key string. Still open since June 12.Closed issues (acknowledged & fixed, but revealing the pattern):
reasonix update/reasonix upgrade自更新命令 #3059 — Request forreasonix updateCLI command (closed, June 5)Why this matters — drawing from other projects
The developer tooling space has converged on a clear consensus: auto-update is not a "nice-to-have" — it is core infrastructure. A few examples:
VS Code pioneered the "silent background update + apply on restart" model. Its update mechanism is considered a key competitive advantage — users rarely think about versioning because it just works. The team has written extensively about how seamless updates reduce their support burden by keeping the user base on a narrow version band.
Firefox invested heavily in Background Update (Project Balrog) precisely because they found that every manual update step loses ~15-30% of users who simply never get around to it. For a security-sensitive product, that's unacceptable — but for a coding agent that processes your entire codebase, the stakes are arguably comparable.
Homebrew made
brew upgradeandbrew autoupdatea first-class part of the ecosystem. Their philosophy: the default should be "stay current," with opt-out, not opt-in.Rust's
rustupdemonstrates that even CLI-first tools can have a frictionless self-update story.rustup updateis a single command that handles toolchain, components, and targets atomically.Claude Code (a direct competitor) auto-updates on every
npm install -g @anthropic-ai/claude-codeinvocation and nudges users withclaude updatewhen a new version is detected. Reasonix'sreasonix updateexists ([Feature Request] 添加reasonix update/reasonix upgrade自更新命令 #3059) but lacks proactive notification.Suggested priorities
With respect for the team's bandwidth, I'd suggest these as high-impact, incremental steps rather than a single monolithic effort:
Fix the Windows update failure ([Bug]: Update failed after clicking “Check for updates” #4078) — This is a regression-level issue. Users who click "Check for updates" get an error. That's the worst possible UX for an update mechanism: it teaches users not to trust it.
macOS/Linux in-app auto-update ([Feature]: 希望mac支持自动更新，而不是每次手动下载安装包替换，太麻烦了 #4777) — For the desktop app, Sparkle (macOS) and AppImageUpdate (Linux) are mature, battle-tested libraries. Given that Windows already has update-resume and retry (fix(desktop): make the updater download resilient — retry, resume, IPv4 fallback #4141), bringing macOS and Linux to parity would complete the story.
CLI proactive update notification — When
reasonix codestarts, check if the current version is the latest (a lightweightHEADto the releases API). If not, show a non-blocking hint:"A new version (vX.Y.Z) is available. Run 'reasonix update' to upgrade."This is whatnpm,pnpm,yarn, andcargoall do, and it's remarkably effective at keeping users current.Version migration smoke test — Issues [Bug]: 无法将0.53.0聊天记录迁移至1.6.0 Cannot migrate chat history from 0.53.0 to 1.6.0 #4156 and [Bug]: 0.53.0可以升级到1.6.0了吗，之前好多bug #4251 showed that the 0.x → 1.x migration left some users unable to see their chat history. As the project matures and release cadence accelerates, a CI test that verifies "upgrade from version N-1 to N preserves sessions and config" would catch these before users do.
Closing thought
Reasonix has a genuine architectural moat in the cache-first loop. But that moat only protects users who are running the latest version with the latest optimizations. Every user stuck on an old version because the update path was too painful is a user not benefiting from the team's relentless shipping velocity — and potentially filing bugs that have already been fixed.
The team has already done excellent foundational work (#4141 retry/resume, #4742 Authenticode signing, #3280 portable releases). I'd humbly suggest that consolidating these into a cohesive, cross-platform, zero-friction update experience would be one of the highest-leverage investments for the project's next chapter.
Thank you for reading, and again — incredible work on Reasonix. 🙏
Related issues
reasonix update/reasonix upgrade自更新命令 #3059, Update error banner has no dismiss button — stuck on screen when offline #3699, fix(desktop): make the updater download resilient — retry, resume, IPv4 fallback #4141, fix(desktop): improve Windows install updates and portable release #3280, [Bug]: 无法将0.53.0聊天记录迁移至1.6.0 Cannot migrate chat history from 0.53.0 to 1.6.0 #4156, [Bug]: 0.53.0可以升级到1.6.0了吗，之前好多bug #4251, ci(desktop): Authenticode-sign Windows installer via SignPath #4742, ci(desktop): gate stable Windows signing until the release cert is ready #4749 (closed)