pastilhasandClaude Opus 5
0e893cc292
The symlink existed because the Claude sidecar hardcoded that path, and that hardcoding came from the bwrap-sandboxed architecture: the jail ro-bound /usr and could not see the installer's real target in ~/.local/bin. The sandbox is gone, and claude-manager.ts now resolves the CLI itself — $CLAUDE_BIN, then PATH, then ~/.local/bin/claude, /usr/local/bin/claude, /opt/homebrew/bin/claude. Verified before removing rather than assumed: - the only references left in the tree are the resolver's own fallback list and this step; nothing in capabilities, no systemd unit, no crontab, no ecosystem file and no shell rc mentions the path - the agent sidecar's PATH under pm2 contains ~/.local/bin ahead of /usr/local/bin, so Bun.which resolves to the installer's target and the symlink is never consulted - replaying the resolver in that exact environment with the symlink treated as absent returns the same path, so it is not load-bearing - resolveClaudeBin runs at claude-manager module scope, which ES import ordering puts before user-instance.ts reassigns process.env.HOME — so the homedir() candidate is evaluated against the real home, not the managed one The install-and-verify step above is untouched, so a failed claude-code install is still reported. Only the sudo-owned link into /usr/local/bin goes, a directory macOS does not ship at all. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>