fix: prompt for catalog provider API keys and clarify update behavior - #7
Conversation
install.sh and install.ps1 were carried over from the Python pythinker-cli repo: they resolved v-prefixed tags and downloaded pythinker-VERSION-.tar.gz / PythinkerSetup-.exe assets that this repo never publishes, so both installers polled GitHub for ~6 minutes and failed without downloading. Resolve the version from the CDN latest file (GitHub API fallback), download pythinker-code-<target>.zip from the @pythoughts/pythinker-code@X.Y.Z release tag, verify SHA-256, and install the extracted binary. Windows now extracts pythinker.exe to LOCALAPPDATA\Programs\Pythinker and persists it on the user PATH instead of running the removed Inno Setup installer.
Catalog provider login (TUI /login and /provider, and openai-api / anthropic-api which route through the same path) failed with 'Environment variable X is not set or is empty' instead of asking for a key. Fall back to the API key dialog and store the literal key via applyCatalogProvider's existing apiKey field. The CLI command 'pythinker provider catalog add' gains --api-key for the same case.
Homebrew is deliberately excluded from background auto-install (canAutoInstall), matching gh and Claude Code, but /update and the startup notice implied auto-update exists. Both now state the brew upgrade command and point to the native installer for automatic background updates. ManualUpdateResult carries the install source so the TUI can branch on it.
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 36 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe change adds catalog API-key prompting and literal CLI key support, updates Unix and Windows native installers to use published ZIP assets, adds Homebrew update guidance, and introduces site presentation changes. ChangesCatalog credentials
Native installers and updates
Site presentation and documentation
Estimated code review effort: 4 (Complex) | ~45 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Comment |
Allowlist 'iterm' (iTerm2 identifier) for the whole-repo spell check, and initialize the pwsh error variable in the install-script smoke so ParseFile's [ref] argument is valid.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/pythinker-code/test/tui/commands/auth.test.ts`:
- Around line 116-125: Update the cancellation test around
connectCatalogProvider to assert that setConfig was not called, in addition to
verifying the provider remains unset and model selection is skipped. Ensure the
setConfig mock is reset or available before the test so the assertion
specifically detects configuration writes during the cancelled key-prompt flow.
In `@apps/pythinker-web/public/install.ps1`:
- Around line 458-459: Update the architecture selection near $archLabel to
accept only RuntimeInformation OSArchitecture values X64 and Arm64, mapping them
to x64 and arm64 respectively; reject X86 and any other or future value before
assigning $target or constructing the asset URL.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 89c2d424-c237-4cf5-844d-fb1a69ef611e
⛔ Files ignored due to path filters (1)
docs/media/Architecture.webpis excluded by!**/*.webp
📒 Files selected for processing (18)
.changeset/catalog-provider-api-key-prompt.md.changeset/homebrew-update-hint.md.changeset/native-install-script-assets.mdREADME.mdapps/pythinker-code/src/cli/sub/provider.tsapps/pythinker-code/src/cli/update/preflight.tsapps/pythinker-code/src/tui/commands/auth.tsapps/pythinker-code/src/tui/commands/info.tsapps/pythinker-code/test/cli/provider.test.tsapps/pythinker-code/test/cli/update/preflight.test.tsapps/pythinker-code/test/tui/commands/auth.test.tsapps/pythinker-code/test/tui/pythinker-tui-startup.test.tsapps/pythinker-web/public/install.ps1apps/pythinker-web/public/install.shapps/site/src/App.vueapps/site/src/components/AgentLoop.vueapps/site/src/components/InstallCommand.vueapps/site/src/components/LegacyDownloadsPopup.vue
Reject unsupported Windows architectures in the install script instead of defaulting to x64, and assert that cancelling the API key prompt writes no configuration.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/pythinker-web/public/install.ps1 (1)
500-503: 🩺 Stability & Availability | 🟡 Minor | ⚡ Quick winHandle a running
pythinker.exeduring manual installs. Windowspythinker upgradeprints theinstall.ps1command and does not launch it. However, direct copying can fail if another process holdspythinker.exe; stop the process or use staged replacement.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/pythinker-web/public/install.ps1` around lines 500 - 503, Update the manual installation flow around the binary Copy-Item to handle an already-running pythinker.exe, stopping the relevant process or using a staged replacement before copying the new binary into installDir. Preserve the existing destination path and Phase-Ok "Installing" completion behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/pythinker-web/public/install.ps1`:
- Around line 458-463: Update the architecture detection immediately before the
$archLabel switch to identify the native Windows ARM64 platform even when the
current PowerShell process is emulated as x64, using a runtime-independent
signal or an explicit supported-runtime requirement. Ensure native ARM64 selects
'arm64', genuine x64 selects 'x64', and unsupported architectures still call
Fail.
---
Outside diff comments:
In `@apps/pythinker-web/public/install.ps1`:
- Around line 500-503: Update the manual installation flow around the binary
Copy-Item to handle an already-running pythinker.exe, stopping the relevant
process or using a staged replacement before copying the new binary into
installDir. Preserve the existing destination path and Phase-Ok "Installing"
completion behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: a62f5e09-25c1-4630-b5fa-26245437fac6
📒 Files selected for processing (2)
apps/pythinker-code/test/tui/commands/auth.test.tsapps/pythinker-web/public/install.ps1
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/pythinker-code/test/tui/commands/auth.test.ts
npm installs the CLI on any Node version (engines is a warning for consumers), but the TUI requires node:ffi via --experimental-ffi, which Node 24 does not have — the re-exec died with 'bad option'. Check the runtime version before re-exec and print the requirement plus the native-installer alternative.
An x64-emulated PowerShell on Windows ARM64 reports OSArchitecture=X64 and would install the x64 build. Read the machine architecture from the Session Manager registry key (with env-var fallback), which reports the hardware architecture regardless of process emulation.
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## @pythoughts/pythinker-code@0.6.1 ### Patch Changes - [#7](#7) [`d396320`](d396320) - Prompt for an API key when connecting a catalog provider whose environment variable is not set, instead of failing with "Environment variable is not set or is empty". Applies to `/login`, `/provider`, and `pythinker provider catalog add`, which now also accepts `--api-key <key>`. - [#7](#7) [`d396320`](d396320) - Explain in `/update` and the startup update notice that Homebrew installs do not auto-update, and point to the native installer for automatic background updates. - [#7](#7) [`d396320`](d396320) - Point the native install scripts at the published release assets. - [#7](#7) [`d396320`](d396320) - Show a clear requirement message with the native-installer alternative when the CLI is launched on Node.js older than 26.4, instead of failing with a cryptic flag error. - [#8](#8) [`9b1b195`](9b1b195) - Fix the CLI failing to start on Windows with "process.execve is unavailable" by using the spawn fallback instead of calling execve there. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Related Issue
No linked issue — problem explained below.
Problem
Connecting a provider from the models.dev catalog in
/loginor/providerfailed withEnvironment variable "X" is not set or is empty.instead of asking for an API key. The same gate also broke the OpenAI (API key) and Anthropic (API key) login entries, which route through the same path, andpythinker provider catalog addhad no way to pass a key directly. Separately, the update banner and/updateimplied Homebrew installs auto-update when they deliberately do not, and the native install scripts pointed at nonexistent release assets.What changed
config.tomlvia the existingapi_keyprovider field. When the env var is set, behavior is unchanged.pythinker provider catalog addgains--api-key <key>, taking precedence over--api-key-envand the catalog's declared env var; error messages now mention the flag./updateand the startup update notice state that Homebrew installs do not auto-update and show the native installer command for automatic background updates.Tests: new coverage for the prompt fallback (env set / unset / undeclared / cancelled) in the TUI, and for
--api-keyprecedence and Commander wiring in the CLI. Full suite green.Checklist
gen-changesetsskill, or this PR needs no changeset.gen-docsskill, or this PR needs no doc update.Summary by CodeRabbit
New Features
--api-key.Bug Fixes
Documentation