kbagent: /kbagent:setup cannot complete login in-chat, in any client

[eruveo]

/kbagent:setup cannot finish setup in any client today, because the browser login is always handed back to the user's terminal. Verified across three clients on 2026-08-26.

What was tested

Client	Adds the marketplace	Runs plugin slash commands	/kbagent:setup finishes
Claude Code	/plugin marketplace add keboola/ai-kit	yes	no — hands auth login to the user's terminal
Cursor	UI only, and it needs the full URL https://github.com/keboola/ai-kit. The keboola/ai-kit short form is rejected with [invalid_argument] Error	yes	no — same handoff
Claude Desktop	UI only (Customise → Plugins → Add → Add from marketplace)	no — /kbagent:setup returns "Unknown command", /plugin returns "/plugin isn't available in this environment"	n/a

In Cursor the command got as far as: CLI present (v0.91.0), project list empty, then stopped with "browser login has to happen in your terminal" and printed kbagent auth login --stack <url> --register-projects for the user to run.

Correction to an earlier version of this issue. Cursor being usable at all in that session came from a login done earlier in Claude Code, not from anything Cursor did. All clients read the same local config, so once any one of them is signed in the others inherit it, and a client can look like it completed setup when all it did is find someone else's session. Worth keeping in mind when testing this: log out first, or you are testing the shared config rather than the client.

Why it stops

plugins/kbagent/commands/setup.md step 3 treats browser login as a human action the agent must not attempt. That is a defensible rule, but the consequence is that the one command we tell users to run cannot complete on its own, in any client. The documented "three commands and you are set up" flow is really "three commands, then go to a terminal anyway".

Asks

1. Make login completable from a chat client. Something has to open the browser and see PKCE through without the user changing windows to a terminal. Options worth weighing rather than one prescribed fix:
   • Let the agent run auth login backgrounded, since the failure the rule guards against is a foreground timeout killing PKCE mid-flow, not the login itself being unsafe.
   • Or a device-code path the agent can drive and surface, with the user only approving in the browser.
   • Or have setup detect that it cannot complete and say so up front, rather than after two of its four steps.
2. The delivery mechanism has to differ by client, because a command cannot reach Claude Desktop.
   • Cursor already runs plugin slash commands, so /kbagent:setup is the right shape there. Only the login policy is in the way.
   • Claude Desktop has no command surface at all, so nothing prefixed / will ever reach it however the plugin is installed. Setup has to arrive as a skill the agent invokes from natural language ("set up Keboola", "log me out"), not as a command. The plugin already ships skills, so this is a question of teaching one the setup and logout verbs rather than adding a surface.
3. Document the per-client marketplace source format. Cursor's full-URL requirement is not discoverable and the error is [invalid_argument] Error, which says nothing.

Why it matters now

keboola/ui#8104, keboola/keboola_com#531 and keboola/connection-docs#1095 all document the setup command. They have been written around these limits (Claude Desktop is on the manual flow, Cursor keeps install-connect-verify), so nothing is currently lying to users. But the short flow only becomes real once login can complete in-chat, and that is this issue.

One nice thing found while testing, worth keeping: login is shared across clients. Signing in from any tool is picked up by the others, because they all read the same local config. That is worth saying out loud in the docs, and worth not breaking.

[eruveo]

Two more findings from wiring this into the product guide.

1. doctor's plugin check cannot see a Cursor install. _check_claude_plugin in services/doctor_service.py probes ~/.claude/plugins/cache/<marketplace>/kbagent/<version>/, which is Claude Code's cache layout. Cursor installs the same plugin from the same marketplace and stores it elsewhere, so on Cursor the check reports the plugin missing (or skips, if ~/.claude does not exist) even immediately after a successful install. The check is named claude_plugin and the docstring says "Claude Code plugin", so this is arguably working as designed, but the marketplace is no longer Claude-only and the message a Cursor user gets is wrong. Either widen it per client or say plainly that the check covers Claude clients only.

2. The plugin is not required to get working, which is worth being explicit about. kbagent project add --project X --url Y --token … is enough for any client with a shell: the agent can drive the CLI immediately. What the plugin adds is that the agent knows the surface, which is why the clients with no marketplace are told to run kbagent context instead. So the plugin is an upgrade rather than a prerequisite, and kbagent context is its manual substitute. Worth saying in setup.md and in the docs, because the current framing reads as though the plugin is part of getting connected.

Together these two argue that the plugin does not belong inside the connect-and-verify sequence for clients other than Claude Code: doctor cannot confirm it for some of them, and nothing in the sequence depends on it.