Connect Qwen Code to Busabase

Known gotchas

Qwen Code's documented OAuth configuration expects explicit client ID, client secret, authorization URL, and token URL. That is not Busabase's preferred dynamic-registration flow, so use the Skill path unless you provision a static client. Separately, the interactive `/mcp-config login <server>` flow performs OAuth discovery against the server's authorization-server metadata and can reuse a client another tool already registered for the same issuer (the docs name Claude Code); the settings-file `oauth` object itself still takes explicit static client fields, so auth-mode stays oauth-static-client. Current docs also add two security rules: servers whose name contains `qwen` in any case are excluded, and environment-variable expansion inside `mcpServers` is limited to an allowlist (`QWEN_CODE_MCP_ALLOWLIST` or a `.env` file). One correction to the framing above: `clientId` is in fact optional — when it is omitted, Qwen Code uses dynamic registration, and authorization/token URLs are auto-discovered when omitted, so the static path is an option rather than a requirement (auth-mode stays oauth-static-client as the fully documented settings-file path). In the JSON config the remote-HTTP field is `httpUrl` — writing `url` instead selects SSE. On remote servers, cloud IDEs or web terminals the default localhost OAuth redirect (http://localhost:7777/oauth/callback) does not work; set --oauth-redirect-uri to a public /oauth/callback URL proxied to 127.0.0.1:7777. OAuth tokens are stored unencrypted by default in ~/.qwen/mcp-oauth-tokens.json (mode 0600); set QWEN_CODE_FORCE_ENCRYPTED_FILE_STORAGE=true on shared machines. The Quickstart now recommends the standalone install script; the npm install remains as the manual path.