Plan: make updater preserve renamed binary commands

[shiny-code-bot]

Objective

Users can install or rename the executable to a local command such as chris-code while still using the GitHub Release self-updater. The updater should treat the release payload name as an implementation detail and replace the executable path the user is actually running.

This is specifically for renamed local binaries in the cbusillo/code distribution. It is not a rebrand and should not require publishing duplicate release assets for every local command name.

Finish Line

Running chris-code update --yes from a directly managed install downloads the standard code-<target> release payload and installs it over the existing chris-code executable path, with update-check/update output naming the real local command and target path instead of hard-coding code.

Current Status

State: Implemented locally on branch fix/lab-updater-identity; awaiting review/PR.
Next action: Review the branch diff, then open a PR when ready.
Blocked by: None
Waiting for: Review/PR creation.
Last verified: 2026-05-30 with cargo test -p code-cli --bin code update, cargo test -p code-tui updates::tests::upgrade_resolution, git diff --check on touched files, and ./build-fast.sh.

Scope

• In: Detect the invoked/local command name, preserve the actual executable install target, extract the existing release payload, and install it over the renamed executable path.
• In: Treat /usr/local/bin as a direct self-update location only when the canonical executable target is an unmanaged binary; package-manager paths reached through symlinks remain refused.
• In: Update updater copy/hints such as Run code update-check and TUI upgrade copy such as code update --yes so they use the detected command name where possible.
• In: Pass an explicit command name from JS/npm wrappers when available, alongside the existing CODE_BINARY_PATH handoff, for display/diagnostics only.
• In: Tests for renamed direct binaries, install-source classification, /usr/local/bin, and symlink behavior.
• Out: Publishing separate release archives named after downstream/local binary names.
• Out: Rebranding crate names, package names, config dirs, or the code executable default.
• Out: Supporting self-update for package-manager managed installs that are currently refused, such as Homebrew/npm/cargo installs.
• Out: Using sudo or privilege escalation for updates; permission failures should produce clear manual-install guidance.

Acceptance Criteria

• A directly managed executable named chris-code can self-update using the standard release manifest and payload.
• The updater replaces the canonical install target path and does not require the local filename to equal code.
• A real unmanaged binary at /usr/local/bin/chris-code is eligible for direct self-update when permissions allow.
• A symlink invocation updates the canonical executable target and keeps the symlink itself intact.
• A symlink that resolves into Homebrew/npm/cargo/package-manager-owned paths is still refused.
• Permission failures in /usr/local/bin do not escalate; they produce clear manual-install guidance.
• update-check, update, doctor, and TUI upgrade prompts include the actual local command name and install target path where useful.
• Command-name fallback order is explicit: CODE_COMMAND_NAME, then argv/current-exe basename, then install-target basename.
• The npm/JS wrapper exports CODE_COMMAND_NAME to the native binary without breaking CODE_BINARY_PATH; this is diagnostic/display identity only and does not make npm-managed installs self-updateable.
• Archive extraction still trusts the release manifest/payload name, not the local command name.
• Existing release manifest schema remains compatible.
• Focused tests cover chris-code/renamed executable behavior, /usr/local/bin, symlink behavior, install-source classification, and existing code-<target> archive extraction.

Relationships

• Related to the Every Code Lab identity plan because both need runtime identity terms, but this issue owns updater behavior only.

Validation

• Add/update focused Rust tests in code-rs/cli/src/update.rs for renamed binary paths, symlink canonicalization, install-source classification, and archive extraction.
• Add/update focused TUI updater tests in code-rs/tui/src/updates.rs if upgrade display text changes there.
• If wrapper logic changes, validate the JS path by inspection or an existing package test if available.
• Run the required repository gate from the root: ./build-fast.sh.

Decisions

• Keep release asset names stable as code-<target> assets.
• Treat local names like chris-code as install target/command identity, not release payload identity.
• Use CODE_COMMAND_NAME as the Every Code-owned wrapper-to-native command identity variable.
• Allow /usr/local/bin for direct unmanaged binaries, but never use sudo or privilege escalation.
• Preserve refusal behavior for package-manager managed installs, including symlink targets that canonicalize into Homebrew/npm/cargo locations.
• Symlinked launches should update the canonical target path and leave the symlink intact.

Open Questions

• None currently.

[shiny-code-bot]

Completed in the v0.6.109 release.

Evidence:

• Implementation PR: fix(update): preserve renamed binary identity #241
• Release metadata PR: release: prepare v0.6.109 metadata #243
• Snapshot follow-ups: test(tui): normalize Lab header snapshots #245 and test(tui): stabilize Lab snapshot normalization #247
• Release workflow: https://github.com/cbusillo/code/actions/runs/26697046333
• Published release: https://github.com/cbusillo/code/releases/tag/v0.6.109

Outcome:

• The updater now carries the invoking command name through CODE_COMMAND_NAME so renamed wrappers such as chris-code update the expected binary identity.
• The TUI auto-upgrade path avoids sudo retry behavior; unmanaged direct binaries in locations such as /usr/local/bin can still update themselves when writable.