Make the install scripts read like a finished product

[zmofei]

The installers worked, but a first install ended in a wall of text with no next step, and on a fresh Mac ~/.local/bin is not on PATH, so most first runs ended in command not found. Now that mapbox mcp (#69) has landed, the installer also offers to add the Mapbox MCP servers, next to the skills question from #61.

install.sh

• Adds the install dir to PATH by appending one line to the shell profile (zsh with ZDOTDIR, bash, fish, otherwise ~/.profile). On macOS, bash uses an existing .bash_profile, .bash_login or .profile rather than creating a .bash_profile that would stop a login bash reading .profile. Never writes the line twice, and only a whole-path mention of the dir outside a comment counts as already there. MAPBOX_NO_MODIFY_PATH=1 opts out, the same switch install.ps1 already has.
• One line per step, a progress bar while downloading (terminal only, erased when done), color under the CLI's own rules (NO_COLOR, TERM=dumb), ASCII marks outside a UTF-8 locale.
• Long steps (pipx/pip, mapbox mcp install) show a spinner with the command's latest output dimmed under it, erased when done. A line with a URL, such as a sign-in page, is printed in full above it and stays. No spinner under TERM=dumb.
• Writes a log of each run to ~/.local/state/mapbox-cli/install.log ($XDG_STATE_HOME when set): every step line, and each mapbox and Tilesets command it ran after installing the binary, with its full output and exit status. The previous run's is kept as install.log.1.
• Ends with "is ready", the PATH line for the current shell when needed, mapbox auth login, docs, and the telemetry notice.

MCP servers (both scripts)

• After the skills question, asks whether to add the Mapbox MCP servers to the coding agents it finds (Claude Code, Codex, VS Code, Cursor) by running mapbox mcp install --global. Asked only at a terminal and only when something is not registered yet; the default is no. MAPBOX_CLI_NO_AGENT_SETUP=1 skips it with the skills question.
• Each question says which command a yes runs. Results are nested under the question and grouped per server and outcome, so one added now reads differently from one already there or one whose sign-in did not finish.

install.ps1

• Same layout, using Write-Host -ForegroundColor so it works on 5.1 and conhost. ✓ only in Windows Terminal; the file stays ASCII.
• No spinner and no install log: mapbox mcp install's live output goes straight to the console.

Both

• REPO pointed at github.com/mapbox/cli, which is a 404. Now mapbox/mapbox-cli.

Tested

• cargo fmt, clippy -D warnings and cargo test pass. test-install.sh passes locally and shellcheck is clean.
• New test-install.sh cases cover the profile edit, idempotency, ZDOTDIR, fish, MAPBOX_NO_MODIFY_PATH, color, a failed pipx install, and the MCP question: no terminal, yes, no, already registered, a failed registration, a row carrying an error key (with braces in it), grouping, nesting, the install log, a log line too wide for the terminal, a sign-in URL, TERM=dumb, a near-miss mention of the dir in a profile, and bash on macOS with an existing .profile. Most were checked by breaking the code they guard and watching them fail.
• Ran install.sh by hand on macOS with a binary built from this branch, answering yes to the MCP question (before the last commit, which fixes what review found).

Test on mac

Test on Win

$env:MAPBOX_CLI_BASE_URL = 'https://cli.mapbox.com'
irm https://raw.githubusercontent.com/mapbox/mapbox-cli/feat/installer-ux/scripts/install.ps1 | iex

Both screenshots predate the MCP question.

Not checked

• install.ps1's MCP question and its answered paths have not been run anywhere: there is no pwsh on the Mac I worked on, and test-install.ps1 runs -NonInteractive, so it reaches only the no-console path. The Windows VM run above predates them.
• The MCP question shows up only with a CLI that has mapbox mcp, so it stays hidden until a release after 0.3.0.
• Codex reports the sign-in as unfinished against the hosted servers (AGI-1166); the installer reports that rather than fixing it.
• install.sh by hand on Linux: the progress bar, spinner, color and ~/.bashrc edit there are covered only by CI's run. The profile check uses awk; this Mac has only BSD awk, so mawk and gawk are exercised only on CI's Linux runner.

[mattpodwysocki]

Built the branch, ran cargo build/fmt/clippy -D warnings/test (all green), shellcheck on both shell scripts (clean), and test-install.sh/test-install.ps1 against this branch (all cases pass). CI is green across all 8 checks too.

One thing worth flagging before either of us merges: this conflicts with PR #61 (still open), which also touches install.sh and install.ps1 in the Tilesets CLI region. I simulated the merge both ways and the install.ps1 side is a trivial 7-line conflict, but install.sh is a real one: #61's coding agent skill section sits right where this PR's tilesets_step() rewrite lands. Posting a separate comment with details so whoever merges second isn't caught off guard.

[mattpodwysocki]

Heads up on a merge conflict this PR will hit against #61 (still open), since neither is merged yet. I simulated the merge with git merge-tree to see what it actually looks like:

install.ps1: small, about 7 lines. Both PRs add a block right before the closing } finally {. Just needs reordering, no real design tension.

install.sh: a bigger one. #61's coding agent skill section sits right after the shared have_tty/ask/is_yes/is_no helpers and before the old Tilesets flow, placed there specifically to run before the script's old inline exit 0 calls in that section. This PR rewrites that whole flow into tilesets_step() using return instead, plus the new Summary block at the end, so the two land on the same region.

The good news is this PR actually removes the reason #61's section had to go where it did: with no more exit 0 landmines in the Tilesets flow, #61's section can move pretty much anywhere in that area once this merges. So whoever merges second just needs to manually re-place that section rather than untangle a real design conflict.

Not a defect in this PR, just flagging it so neither of us is surprised by the conflict when we go to merge.

[zmofei]

@mattpodwysocki ready for another look. Rebased on main after #61 and #69 merged. Your commit is unchanged apart from merging in #61's agent-skills step, and everything since is in one commit: 330da53.

• The merge conflict you flagged: Set up the coding agent skill during install.sh/install.ps1, with explicit consent #61's agent-skills step stays ahead of Tilesets, now in the step-line style, and its comment about the old exit 0 calls is gone.
• New: a separate, default-no question that runs mapbox mcp install --global, asked only at a terminal and only when something is not registered yet. Results are nested under the question and grouped per server.
• install.sh: spinner with live output for long steps (a sign-in URL is printed in full and kept), an install log at ~/.local/state/mapbox-cli/install.log, and safer profile handling (bash on macOS keeps an existing .profile; a near-miss mention of the dir no longer counts as already on PATH).

Not checked: install.ps1's MCP question has not been run anywhere, since test-install.ps1 runs -NonInteractive and I had no Windows machine. Details are in the PR description.