AUR packages and packages in general doesn't and should never touch the user's home.

Upon launching Claude Code, a notification pops up on the right saying that .local/bin/claude cannot be found.

I've noticed that the official installation script creates a symbolic link for .local/bin/claude (e.g., .local/bin/claude -> /home/username/.local/share/claude/versions/2.1.123*), but this AUR package doesn't do that.

Hi @maxemann96 - thanks for the heads up. Fixed.

The official installation script now does not use the bucket url anymore (under the hood it's also a google storage IP), but now uses https://downloads.claude.ai/claude-code-releases/${pkgver}/${platform}/claude. Would be happy to see this reflected in the PKGBUILD. Thanks for your work :)

Thanks for asking.

Under the AUR submission guidelines, packages that use prebuilt deliverables should normally use the -bin, which makes the packaging model explicit.

I agree that the installed program is effectively the same, and this is not intended as a downstream fork or feature-different variant.

The reason I chose a separate claude-code-bin package is to provide a clearly named binary package with a maintainer-side automation pipeline:

https://github.com/fabifont/claude-code-bin

There are also a few packaging differences. This package installs the binary under /usr/lib/claude-code rather than /opt, uses a pinned upstream LICENSE.md source with a checksum instead of SKIP, declares provides=('claude-code=...') and conflicts=('claude-code'), and keeps the PKGBUILD/.SRCINFO update flow automated on the maintainer side.

I'm open to coordinating if the preferred outcome is co-maintenance, a rename/merge path, or another arrangement that avoids confusion.

Why was this created as an almost exact copy of the existing claude-code package?

@cg505 Correction: I tested by running env -u DISABLE_AUTOUPDATER /opt/claude-code/bin/claude --chrome-native-host directly and it starts fine — no crash. The auto-updater isn't the cause.

The environment.d suggestion doesn't apply here; sorry for the noise — that was towards the end of a long debugging session and I jumped to a conclusion.

@aptinio I'm not happy polluting the global environment with this env var. Are you able to see where the /opt/claude-code/bin/claude is coming from? E.g. is it looking at the /proc/<pid>/{cmdline,exe}? We can brainstorm some other solution.

In any case, it doesn't make much sense that /opt/bin/claude-code/bin/claude crashes without DISABLE_AUTOUPDATER=1, and in fact I can't reproduce this issue at all. claude --chrome seems to work fine even on an outdated version of claude code.

fixed, changed to SKIP for the future