@khalilgharbaoui/opencode-claude-code-plugin 0.63.2 → 0.63.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@khalilgharbaoui/opencode-claude-code-plugin",
-  "version": "0.63.2",
+  "version": "0.63.3",
   "description": "Claude Code CLI provider plugin for opencode",
   "homepage": "https://opencode-claude-code-plugin.dev/",
   "funding": {

package/skills/claude-code-plugin/SKILL.md

@@ -1462,7 +1462,7 @@ Prefer the doctor: it needs no logging change and no restart.
 | `proxy call still waiting` in the log, or a `task` that looks stuck | Expected: `task`/`task_batch` carry no default deadline, and the line is a status report | `/claude-code-doctor` lists pending calls with tool, age and deadline. Tell a working subagent from a wedged one there before proposing any timeout change; see the note under "Proxy tool names" |
 | An MCP server's tool returns nothing useful, and `plugin.log` carries `MCP server asked for operator input and was declined` | That server raised an MCP **elicitation**, a mid-call request for the operator to type or choose something. The Claude Code session the plugin drives is headless, so there is nobody to ask: the plugin answers `{"action":"decline"}` under the CLI's documented schema and warns once per server. The tool call still returns and the turn continues | Not configurable, and deliberately so: accepting would mean inventing the answer the server asked for. Run that server's flow in Claude Code directly, where its own dialog can take the input, or configure the server so that path does not elicit |
 | An MCP server's tools are simply absent | Claude Code could not connect that server | Read the once-per-process WARN at session start, and the doctor's **MCP config entries Claude Code skipped** section for one the CLI refused outright. `mcpServers` in the ready block is disk discovery, not live connectivity; fix the server where it is configured |
-| `MCP server "<name>" is needs-auth in Claude Code`, for a remote server that works in opencode | Whether the user authenticated it through opencode's own OAuth flow. opencode holds that token; the bridged config carries no credential, so the CLI cannot connect and the server is dead for the whole session | On opencode **1**, `bridgeMcpOauthTokens: true` hands the CLI the token opencode already has. Tell the user what it does before suggesting it: it copies a credential out of opencode's own store into the bridged `0600` config. On opencode **2** there is no such file and the option finds nothing, so the fix is configuring that server for Claude Code directly |
+| `MCP server "<name>" is needs-auth in Claude Code` (or `N MCP servers are needs-auth ...` listing several), for a remote server that works in opencode. A `claude.ai` connector the account never connected (not in the CLI's `claudeAiMcpEverConnected`) is never warned about: it is logged at INFO and listed in `/claude-code-doctor` | Whether the user authenticated it through opencode's own OAuth flow. opencode holds that token; the bridged config carries no credential, so the CLI cannot connect and the server is dead for the whole session | On opencode **1**, `bridgeMcpOauthTokens: true` hands the CLI the token opencode already has. Tell the user what it does before suggesting it: it copies a credential out of opencode's own store into the bridged `0600` config. On opencode **2** there is no such file and the option finds nothing, so the fix is configuring that server for Claude Code directly |
 | An MCP server opencode has configured is missing on the FIRST turn of a fresh `opencode run`, but present in the TUI | Not a config fault, and mostly fixed. The bridge reads opencode's live MCP status when the turn plans its spawn. On opencode 2 a server still connecting is reported `pending`, which the bridge no longer reads as disabled, and the turn waits up to `mcpConnectWaitMs` (3 s) for the host to decide; opencode 1 cannot reach this state, because its own status call blocks until every server resolves. If the server is slower than the budget it is still bridged, and if it genuinely joins later `hotReloadMcp` moves the conversation onto a process that has it on the next turn, logging `opencode MCP servers changed, respawning claude` with the joined names | Nothing, usually. For a very slow server raise `mcpConnectWaitMs`. Check `plugin.log` for `waited for opencode MCP servers to finish connecting` and for the respawn line; if neither appears and the server is still absent, the status the host reported was a real refusal (`failed`, `needs_auth`), which is opencode's to fix |
 | `permissionPreset` set but nothing about the session looks restricted | The option never reached that provider, or the name is not one the plugin knows (only `read-only` exists) | Read the `permissionPreset` row in `/claude-code-doctor`, or `permissionPresets` in the ready block, for the provider the conversation is on: `none` means it is not configured there (each account is its own provider id), `applied: false` with a name means an unrecognised name applied nothing, and `overrides` lists what an applied preset replaced |
 | `permissionPreset: "read-only"` set, but reads are unconfined or something still prompts | `--restricted` needs CLI 2.1.258 and `--permission-prompts none` needs 2.1.263; below those the preset falls back to `--disallowedTools` plus the plugin's own deny and WARNs naming what is lost | `claude --version`. Below 2.1.258 the working-directory confinement on reads is gone; below 2.1.263 the denial happens in the plugin instead of the CLI. The preset still holds, with one layer fewer |