[zmofei]

Releases the installer's MCP question change as 1.1.1, and notes that published builds now check for updates. Both are fixes, so it's a patch bump.

Release prep

• Cargo.toml and Cargo.lock: 1.1.1.
• CHANGELOG: a ## 1.1.1 - 2026-10-22 heading over both entries.
• README: the version-pinned install examples now name 1.1.1.

The update check line depends on a fix in the release pipeline, which builds every tag as production. 0.3.0 through 1.1.0 were built as staging, which leaves the check off. That fix has to merge before the v1.1.1 tag is pushed, or this line isn't true. If this merges on a later day, the heading's date needs updating.

Testing: cargo test --locked passes, mapbox --version prints 1.1.1, and tests/changelog.rs passes. The README pins point at a v1.1.1 that won't exist until the release is published.

MCP question without a slow pre-check

Before the MCP question, install.sh and install.ps1 ran mapbox mcp install --global --dry-run, which runs each client's own CLI to see what's already registered. Claude Code's takes over a second per call, so the installer sat silent for 3–15 seconds between the skill question and the MCP question, even for people who then answered no or had no terminal.

Now the installer doesn't check clients at all before asking. It asks when the skill step found a coding agent, or when ~/.vscode exists (VS Code takes an MCP server but no skill, so the skill check can't see it). Only a yes runs mapbox mcp install --global, which tries each client, skips any that aren't installed, and reports ones that already have the servers. No and no-terminal runs never invoke mapbox mcp.

Behavior changes:

• The question no longer names clients: "Add the Mapbox MCP servers to your coding agents?"
• A reinstall asks again even when everything is registered. A yes then reports "Mapbox MCP was already in …".
• A no, or no terminal, says "Skipped the Mapbox MCP servers" instead of "not added to …", since nothing checked whether they were missing.
• If the agent found takes skills but not MCP (e.g. only Gemini CLI or Goose), a yes says "No Claude Code, Codex, VS Code or Cursor here to add them to." instead of reporting a failure.
• install.ps1 now captures the mcp install stderr to detect that case while still printing it as it arrives.

Verified:

• cargo build, clippy and test pass, and so does shellcheck.
• scripts/test-install.sh passes. New cases cover a machine with no agent, VS Code only, the opt-out, and an agent with no MCP client. The "never runs mapbox mcp" assertions fail against the old installer, and the VS Code case fails with that gate removed.
• The real CLI's mcp_client_not_found error, with no client installed, has the shape the installer matches.

Not verified:

• install.ps1 and test-install.ps1. There's no pwsh here, so they're CI only. The PowerShell yes path, including the stderr capture, can't be reached by the tests because they have no console.
• A full run of the new install.sh against the dev channel.

[mattpodwysocki]

Thanks @zmofei, nice speedup. Shellcheck is clean, all the test-install.sh cases pass, and cargo test passes with the binary printing mapbox 1.1.1. Asking based on an agent being found or ~/.vscode existing makes sense, and the mcp_client_not_found fallback names the same four clients mapbox mcp install supports. Tiny nit, not blocking: one line in the new changelog entry ("agent or VS Code, and only after a yes does it look for Claude Code, Codex, VS Code") runs past the file's line width. Approving, as long as the release pipeline fix lands before the tag.