claude-code@stable 2.1.74 (new cask)

[chwiese]

After making any changes to a cask, existing or new, verify:

• The submission is for a stable version or documented exception.
• brew audit --cask --online claude-code@stable is error-free.
• brew style --fix claude-code@stable reports no offenses.

Additionally, if adding a new cask:

• Named the cask according to the token reference.
• Checked the cask was not already refused (add your cask's name to the end of the search field).
• brew audit --cask --new claude-code@stable worked successfully.
• HOMEBREW_NO_INSTALL_FROM_API=1 brew install --cask claude-code@stable worked successfully.
• brew uninstall --cask claude-code@stable worked successfully.

---

Claude Code distributes binaries via two channels: stable and latest. The existing claude-code cask currently tracks latest (2.1.81); this new cask tracks stable (2.1.74).

A note on channel semantics: strictly speaking, Acceptable Casks policy favours tracking stable releases, which would suggest claude-code itself should track the stable channel and a claude-code@latest cask could offer the cutting-edge builds. However, renaming the existing cask's channel felt too far-reaching as a first contribution, so I'm starting by adding the stable channel as a new cask and leaving that broader question to the maintainers' discretion.

• AI was used to generate or assist with generating this PR. Used Claude Sonnet 4.6 to research the stable channel URL, compute sha256 checksums for all four platform binaries, and generate the cask file. Manually verified: the stable channel endpoint (claude-code-releases/stable) returns a different version than latest (2.1.74 vs 2.1.81), the livecheck regex matches the version format, all four checksums against downloaded binaries, and the zap stanza paths against a live Claude Code installation on macOS 15.

[bevanjkay]

Thanks @chwiese - I do agree that if both casks are required we should probably set the "versioned" to @stable like you have here.

This is based on my understanding that the installation link provided on the Claude Code website points you to the "latest" branch - if i'm incorrect on this, then we should have claude-code track whatever that version is, and have the opposite in the @suffix cask.

[chwiese]

Thanks @chwiese - I do agree that if both casks are required we should probably set the "versioned" to @stable like you have here.

This is based on my understanding that the installation link provided on the Claude Code website points you to the "latest" branch - if i'm incorrect on this, then we should have claude-code track whatever that version is, and have the opposite in the @suffix cask.

Thanks for reviewing this @bevanjkay. The official install script at https://claude.ai/install.sh does indeed default to the latest channel (version=$(download_file "$GCS_BUCKET/latest")).

[bevanjkay]

I'm ok with including this, although the docs generally suggest the primary cask should track the stable branch, in this case I believe it's best for us to align with upstream (latest branch) and use a "versioned" cask for the alternative branch (in this case stable branch).

I'll leave this open for now to let any other maintainers weigh in or merge as they see fit.

[chwiese]

Based on the discussion above, I had another look at claude codes default behaviour. It enables auto-updating by default and the official installer script runs claude install stable to configure the auto-updater for that channel. I have added the auto_updates true and postflight stanzas to reflect that.

Arguably the claude-code cask should include the auto_updates true stanza as well.

[chwiese]

Reverting to draft to discuss one open question before this is ready to merge.

Background: @bevanjkay's comment about Homebrew detection prompted a deeper look at the Claude Code source. The binary does indeed detect Homebrew installations by checking for /Caskroom/ in process.execPath and, when detected, suppresses self-updating entirely — the background PackageManagerAutoUpdater only shows a notification rather than self-updating. So auto_updates true would be inaccurate and has been reverted.

However, PackageManagerAutoUpdater reads autoUpdatesChannel from ~/.claude/settings.json (defaulting to "latest") to decide which channel to check when building that notification. Without configuring this, a claude-code@stable user would receive "update available" notifications comparing against the latest channel — meaning they'd almost always see a false-positive update prompt even when they're current on stable.

There's a further wrinkle: the notification message itself hardcodes brew upgrade claude-code regardless of which cask is installed, so claude-code@stable users would already be shown the wrong upgrade command. Given that, the autoUpdatesChannel misconfiguration may be a secondary concern — both issues would need a fix upstream in Claude Code itself to be fully resolved.

The question is how to handle autoUpdatesChannel in the meantime. Two options:

1. Write autoUpdatesChannel: stable directly to ~/.claude/settings.json in a postflight block — avoids triggering a full native install (which claude install stable does as a side effect), but involves directly manipulating a user config file from a cask.

2. Add a caveats stanza telling the user to manually set the channel via /config in Claude Code.

Or is the status quo (no special handling) acceptable, given that the notification message is already broken for @stable users regardless, and brew upgrade claude-code@stable remains the correct update path?

[bevanjkay]

Write autoUpdatesChannel: stable directly to ~/.claude/settings.json in a postflight block — avoids triggering a full native install (which claude install stable does as a side effect), but involves directly manipulating a user config file from a cask.

Add a caveats stanza telling the user to manually set the channel via /config in Claude Code.

If anything the second option would be the best here. It may effect the notifications for users to brew upgrade claude-code to only show when stable branch updates are available, which is a good thing. We should avoid writing directly to the file, so caveats is the only option here. Ideally link to documentation that shows how to set this (if possible).

We can't do anything about the in-app upgrade showing brew upgrade claude-code so I think it is what it is.

I also think keeping auto_updates unset is the best option as it will ensure Homebrew users keep the correct version installed as much as possible by running brew upgrade.

[chwiese]

Added a caveats stanza noting that in-app update notifications default to the latest channel, with instructions to configure autoUpdatesChannel via /config and a link to the docs. Also calls out that the hardcoded brew upgrade claude-code in the notification is incorrect for @stable users regardless.

[chenrui333]

Arguably the claude-code cask should include the auto_updates true stanza as well.

it is a terminal app and there is brew upgrade claude-code pop up in the corner indicating the needed upgrade.

[chenrui333]

I am on the fence of including this, users like me using claude code does not care stable and don't know what that means. (I would suggest making an issue to discuss first)

[bevanjkay]

I am on the fence of including this, users like me using claude code does not care stable and don't know what that means. (I would suggest making an issue to discuss first)

I think it's fine to discuss here, we don't need a separate issue.

Not every user needs to us the @stable branch, only those who want to?

[p-linnane]

I'm not convinced this is necessary. Is there really a meaningful difference between the two channels given how quickly Claude Code is released? I use Claude Code regularly and wasn't even aware of this split.

I'd want to see actual user demand before adding an additional cask.

[bevanjkay]

Is there really a meaningful difference between the two channels given how quickly Claude Code is released?

I think that is exactly the point here, it is released quite quickly so there is a second branch that aims to provide a more stable experience for the end-user.

[chwiese]

From the Claude Code documentation:

"stable": use a version that is typically about one week old, skipping releases with major regressions

(emphasis mine)

Especially for users who have deeply integrated Claude Code into their workflows, working without the risk of regressions is valuable.

npm breaks out the number of downloads per tag and while the power of the default (and is evident from comments on this PR, awareness) work in favour of the latest release, stable does see thousands of downloads per week.

[p-linnane]

The regression protection argument is thin. latest is Anthropic's own default channel, so if there's a major regression they're going to cut a fix quickly regardless. And the things users care most about (model quality, reasoning, behavior) are all server-side and completely unrelated to the CLI version.

I also think Anthropic's channel naming is confusing here. Having a @stable cask when the unversioned cask is expected to be the stable option in Homebrew inverts user expectations, and that's not a naming problem we should absorb.

[MikeMcQuaid]

The regression protection argument is thin. latest is Anthropic's own default channel, so if there's a major regression they're going to cut a fix quickly regardless. And the things users care most about (model quality, reasoning, behavior) are all server-side and completely unrelated to the CLI version.

I also think Anthropic's channel naming is confusing here. Having a @stable cask when the unversioned cask is expected to be the stable option in Homebrew inverts user expectations, and that's not a naming problem we should absorb.

Strongly agreed.