commanders: filter the connectors warning, do not silence stderr

ANTHROPIC_BASE_URL points at a local proxy that holds the real credential, so
ANTHROPIC_API_KEY is a token for that proxy — and the CLI sees a key set, assumes
the worst, and warns on every spawn. Nothing is wrong and nothing uses connectors.

But a loop that narrates stderr whenever it is non-empty then narrates this every
single time, which teaches whoever reads the job panel to skim the one channel
that carries real failures. So: filter that known line and report what is left.
Never suppress stderr wholesale — the reason to keep it is the failure nobody has
seen yet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

skills/commander/SKILL.md

@@ -184,6 +184,26 @@ Four details the mechanics do not carry, each of which was learned by getting it
 - **Keep stderr out of a `--output-format=stream-json` pipe.** The CLI prints warnings there — a
   connectors notice, among others — and one of them landing in the stream corrupts the first `jq` parse.
   Redirect it to its own reader.
+- **And filter that connectors notice before you narrate stderr.** On this machine `ANTHROPIC_BASE_URL`
+  points at a local proxy which holds the real credential, so `ANTHROPIC_API_KEY` is set to a token for
+  that proxy — and the CLI sees a key set, assumes the worst, and warns on every single spawn:
+
+  ```
+  ⚠ claude.ai connectors are disabled because ANTHROPIC_API_KEY or another auth source is set…
+  ```
+
+  Nothing is wrong and nothing here uses connectors. But a loop that reports stderr whenever it is
+  non-empty will report this every time, which trains whoever reads the job panel to skim the one channel
+  that exists to carry real failures. Drop it and report what is left:
+
+  ```bash
+  if grep -qv 'claude.ai connectors' "$errlog" 2>/dev/null; then
+    say "stderr: $(grep -v 'claude.ai connectors' "$errlog" | tr '\n' ' ' | cut -c1-200)"
+  fi
+  ```
+
+  Filter by the known line, never by suppressing stderr wholesale. The reason to keep the channel is the
+  failure you have not seen yet.
 - **`jq --unbuffered`**, or the job panel shows nothing for as long as the work takes and reads as hung.
   A background job that produces no output is indistinguishable from a dead one.
 - **The claim goes before the spawn, not inside the action.** If the action claims its own work, an action