@khalilgharbaoui/opencode-claude-code-plugin 0.26.1 → 0.26.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@khalilgharbaoui/opencode-claude-code-plugin",
-  "version": "0.26.1",
+  "version": "0.26.3",
   "description": "Claude Code CLI provider plugin for opencode",
   "author": "Khalil Gharbaoui",
   "type": "module",

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

@@ -232,8 +232,16 @@ Tell the user what a pick actually does before recommending one:
 - `stop`, dismissing the form, or answering with anything that is not one of the offered
   accounts ends the turn exactly as the rate-limit error does today. The limit is
   unchanged either way; failover moves the work, it does not create usage.
-- Only a rejected `rate_limit_event` or one of the two known account-limit error texts
-  opens the form. A generic 4xx, a timeout or a bad flag never does.
+- Only a rejected `rate_limit_event`, one of the two known account-limit error texts, or
+  an account-level failure the CLI reports on its own error reply opens the form. The
+  account-level kinds are `authentication_failed`, `oauth_org_not_allowed`,
+  `account_on_hold`, `verification_required` and `billing_error`. A generic 4xx, a
+  timeout or a bad flag never does.
+- An expired login also writes a `▌ **claude account:**` note naming the account and the
+  command to fix it: `claude auth login` for the default account, or
+  `CLAUDE_CONFIG_DIR=<that account's config dir> claude auth login` for a named one. When
+  a user reports "Failed to authenticate: OAuth session expired", that command is the
+  fix; a switch made from that form lasts until opencode restarts.
 - Not available on the interactive transport or on compaction turns.
 
 `{ "accountFailover": "off" }` keeps the plain rate-limit error.
@@ -343,8 +351,9 @@ Names below become `mcp__opencode_proxy__<name>`; input config is case-insensiti
 A proxied call is held open until an event ends it, and the plugin listens to the
 `claude` process, the stream and the control protocol for those events rather than
 inferring failure from elapsed time: opencode's result resolves the call; an abort
-interrupts the CLI and rejects the turn's pending calls, even when it lands while
-opencode is running the tool; the next user message rejects what the previous turn left pending
+interrupts the CLI and rejects the turn's pending calls, unless opencode still reports
+the session busy (opencode 1.18 aborts the signal of every tool step while it runs the
+tool, so busy means the call is being served, not refused); the next user message rejects what the previous turn left pending
 and tells the CLI; the process exiting, the chat being deleted, or opencode exiting
 rejects the rest. That is why `task` and `task_batch` carry no default deadline and a
 subagent runs to completion. Three timers remain and are distinct from that: the
@@ -352,7 +361,11 @@ optional per-tool deadlines above (a backstop the user chooses), the start and
 inactivity watchdogs (for a process that is alive but silent, which emits nothing to
 listen to; a CLI parked in a proxied call is exempt), and the connection keepalives
 (SSE comments or JSON whitespace every 15 s, so the CLI's HTTP client does not give up
-on a long call; they never extend a deadline). Do not present a raised deadline as the
+on a long call; they never extend a deadline). A deadline that passes while opencode
+still reports the session busy (a permission prompt the user has not answered, or the
+tool still running) does not end the call: it logs `proxy call past its deadline, but
+opencode is still serving it; waiting` at WARN once and is rechecked every minute. So an
+unanswered permission prompt is not a reason to raise `proxyToolTimeoutMs`. Do not present a raised deadline as the
 fix for a long subagent; the default already waits for it. A deadline-free call is not
 silent while it waits: it logs `proxy call still waiting, no deadline` at WARN after
 five minutes and every five minutes after, with tool, call id and elapsed time. That