cowork-harness 3.8.0 → 3.8.1

package/.claude/skills/cowork-harness/SKILL.md

@@ -3,8 +3,8 @@ name: cowork-harness
 description: Test or debug a Claude Code skill/plugin under Claude Cowork's runtime — sandboxed agent, default-deny egress, the can_use_tool permission/question protocol — using the cowork-harness CLI. Use when validating or regression-testing a skill, authoring or debugging a scenario YAML (prompt + scripted answers + assert:), choosing a fidelity tier, scripting AskUserQuestion / tool-permission answers, or asserting artifacts, egress, or sub-agent dispatch. Especially when a harness run no-ops an assertion, fails on an unanswered gate, false-greens, a steered answer never reaches the model, or a web_fetch is unexpectedly denied or gated. Also when iterating or hardening a skill across fixes, or grounding a skill's self-critique against its own run evidence — including a document-analysis skill (cap table, deck, financial model, transcript) that needs an uploaded file attached to be critiqued at all. NOT for generic unit testing (pytest/vitest of your own scripts) or non-Cowork CI. Covers the skill / run / chat / record / replay / trace / decide / assertions / scaffold commands and the session-vs-scenario split.
 metadata:
   author: cowork-harness
-  version: 3.8.0
-  tracks-harness: cowork-harness 3.8.0 (baseline desktop-2.7032.0)
+  version: 3.8.1
+  tracks-harness: cowork-harness 3.8.1 (baseline desktop-2.7032.0)
 ---
 
 # cowork-harness
@@ -25,7 +25,7 @@ flagged with a loud `::warning::`, not silent — auto-answer a gate, observe an
 allowlist). This skill exists mostly to keep you out of those traps — the Gotchas section below is
 the highest-value part. Read it.
 
-> **Version note:** the facts and `file:line` pointers here track `cowork-harness 3.8.0` (baseline
+> **Version note:** the facts and `file:line` pointers here track `cowork-harness 3.8.1` (baseline
 > `desktop-2.7032.0`). If your checkout is newer, prefer the live `--help` and — in a repo checkout —
 > `SPEC.md` / `docs/*.md` over this snapshot, and re-run the bundled linter.
 
@@ -42,7 +42,7 @@ Before the first command, confirm the CLI is reachable and **fail loud** (never
 
 - **One-shot check.** Run `cowork-harness doctor [--tier <tier>]` first — a read-only prerequisite check that inspects Docker, the staged agent, the token, and the baseline in one pass. The bullets below explain each thing it checks (and how to fix it).
 - **Replay-only? Skip `doctor`.** Replaying committed cassettes needs no Docker, no staged agent, and no token — and every tier's `doctor` validates the auth token (the live tiers also Docker + the staged agent), so a ✗ there is expected, not a blocker. Go straight to `cowork-harness replay <cassette>`.
-- **CLI on PATH, recent enough?** Run `cowork-harness --version` — this skill needs **≥ 3.8.0**. If it's missing or older, prefix every command with the version floor `npx "cowork-harness@^3.8.0" <cmd>` (Node ≥ 22), or install once with `npm i -g "cowork-harness@^3.8.0"`. **Pin `@^3.8.0`, never `@latest`** — `@latest` can silently fetch an older CLI and the new commands fail as "unknown command", whereas the floor **fails loud** if no compatible version is published.
+- **CLI on PATH, recent enough?** Run `cowork-harness --version` — this skill needs **≥ 3.8.1**. If it's missing or older, prefix every command with the version floor `npx "cowork-harness@^3.8.1" <cmd>` (Node ≥ 22), or install once with `npm i -g "cowork-harness@^3.8.1"`. **Pin `@^3.8.1`, never `@latest`** — `@latest` can silently fetch an older CLI and the new commands fail as "unknown command", whereas the floor **fails loud** if no compatible version is published.
 
   This skill documents the CURRENT surface, not release history. If `cowork-harness --version` is
   OLDER than the floor, the per-release record of what you are missing is [CHANGELOG.md](https://github.com/yaniv-golan/cowork-harness/blob/main/CHANGELOG.md)

package/.claude/skills/cowork-harness/references/ci-recipe.md

@@ -1,6 +1,6 @@
 # CI recipe — replay vs live lanes
 
-Self-contained reference. Tracks `cowork-harness 3.8.0` (baseline `desktop-2.7032.0`).
+Self-contained reference. Tracks `cowork-harness 3.8.1` (baseline `desktop-2.7032.0`).
 
 **Fastest path: the packaged Action.** One step gets you `replay`/`lint`/`verify-cassettes` plus a PR
 job-summary reporter (verdict table, staleness findings, cost/turns when available):
@@ -17,7 +17,7 @@ job-summary reporter (verdict table, staleness findings, cost/turns when availab
 CLI major reaches your workflow the moment it is promoted even though your `uses:` ref never changed — so a
 copy-pasted recipe that omits the input takes a major bump with no say in it. `^2` holds the major, needs no
 patch number to remember, and only wants a human decision at the next major. Pin an exact version
-(e.g. `version: "3.8.0"`) instead when you want byte-reproducible CI.
+(e.g. `version: "3.8.1"`) instead when you want byte-reproducible CI.
 
 Reach for the manual multi-step form below only when you need per-step control the Action's inputs don't
 cover (a custom flag combination, a different runner matrix per step, or `lint`/`verify-cassettes` gated
@@ -77,7 +77,7 @@ sha256-*checked* but not hard-blocking on mismatch — it's advisory for an inte
 GitHub-hosted runners, no token/Docker/agent:
 
 ```yaml
-- run: npm i -g "cowork-harness@^3.8.0"
+- run: npm i -g "cowork-harness@^3.8.1"
 - run: cowork-harness lint scenarios/*.yaml --strict --min-severity WARN
                                                     # no silent false-greens. WITHOUT --strict this
                                                     # step cannot fail on a WARN-class rule (e.g.
@@ -364,7 +364,7 @@ jobs:
         with: { node-version: '24' }
       - uses: actions/setup-python@v5
         with: { python-version: '3.x' }                                       # python3 only — PyYAML is bundled with the linter
-      - run: npm i -g "cowork-harness@^3.8.0"
+      - run: npm i -g "cowork-harness@^3.8.1"
       - run: cowork-harness lint scenarios/*.yaml                              # no-silent-false-green (needs python3; PyYAML bundled)
       - run: cowork-harness verify-cassettes cassettes/ --output-format json   # privacy + staleness gate
       - run: cowork-harness replay cassettes/ --output-format json             # token-free content/structure
@@ -393,7 +393,7 @@ jobs:
             echo "live=true" >> "$GITHUB_OUTPUT"
           fi
       - if: steps.guard.outputs.live == 'true'
-        run: npm i -g "cowork-harness@^3.8.0"
+        run: npm i -g "cowork-harness@^3.8.1"
       - if: steps.guard.outputs.live == 'true'
         run: cowork-harness run scenarios/ --output-format json
         env:

package/.claude/skills/cowork-harness/references/critique.md

@@ -1,6 +1,6 @@
 # Critique — the facts a plugin install can't otherwise reach
 
-Tracks `cowork-harness 3.8.0` (baseline `desktop-2.7032.0`). This is **not** a trim of the full
+Tracks `cowork-harness 3.8.1` (baseline `desktop-2.7032.0`). This is **not** a trim of the full
 [`docs/critique.md`](https://github.com/yaniv-golan/cowork-harness/blob/main/docs/critique.md) (repo-only —
 flags, cost, reproduction discipline, known limitations all live there). This file covers exactly what a
 plugin install cannot otherwise discover: the run-dir artifact a harvester actually reads, the report's

package/.claude/skills/cowork-harness/references/fidelity-and-answers.md

@@ -1,6 +1,6 @@
 # Fidelity tiers & answer paths
 
-Self-contained reference. Tracks `cowork-harness 3.8.0` (baseline `desktop-2.7032.0`).
+Self-contained reference. Tracks `cowork-harness 3.8.1` (baseline `desktop-2.7032.0`).
 
 > **This page vs. the repo docs.** This is the **offline snapshot** that ships inside the installed
 > plugin — it is self-contained on purpose. The repo carries four other fidelity views, each answering a

package/.claude/skills/cowork-harness/references/scenario-schema.md

@@ -1,6 +1,6 @@
 # Scenario & session schema, assertion catalog, web_fetch, authoring gotchas
 
-Self-contained reference for authoring `cowork-harness` scenarios. Tracks `cowork-harness 3.8.0`
+Self-contained reference for authoring `cowork-harness` scenarios. Tracks `cowork-harness 3.8.1`
 (baseline `desktop-2.7032.0`). If your checkout is newer, prefer the live [`docs/scenario.md`](https://github.com/yaniv-golan/cowork-harness/blob/main/docs/scenario.md),
 [`docs/session.md`](https://github.com/yaniv-golan/cowork-harness/blob/main/docs/session.md), and `SPEC.md`.
 
@@ -192,7 +192,7 @@ plugins:
 skills:
   local: []                      # extra host skill dirs
   suggest_enabled: true          # gate 245679952 override — `mcp__skills__suggest_skills` on/off (default true)
-  proactive_suggest_enabled: false  # gate 1598976391 override — proactive description + `trigger` param; unset = synced baseline gate (ON from 1.24012.11)
+  proactive_suggest_enabled: false  # gate 1598976391 override — proactive description + `trigger` param; unset = always on from the 1.46388.3 baseline (where `false` models a surface production does not ship there), synced gate before it
 mcp:
   config: null                   # --mcp-config file (standard mcpServers map)
   enabled: []

package/.claude/skills/cowork-harness/references/task-recipes.md

@@ -2,7 +2,7 @@
 
 Each recipe composes facts that live scattered across SKILL.md and the other references into one
 decision path. Every one answers a question a real fleet owner had to work out the hard way.
-Tracks `cowork-harness 3.8.0` (baseline `desktop-2.7032.0`), same as SKILL.md's front-matter. Recipe 2's `resolved-tier`/`unverifiable-tier` staleness classes and
+Tracks `cowork-harness 3.8.1` (baseline `desktop-2.7032.0`), same as SKILL.md's front-matter. Recipe 2's `resolved-tier`/`unverifiable-tier` staleness classes and
 Recipe 3's `init-redact` shipped in 0.24.0 and are part of the current feature set — no version gate
 needed if your CLI meets SKILL.md's version floor.
 

package/CHANGELOG.md

@@ -6,6 +6,56 @@ All notable changes to this project are documented here. The format is based on
 
 ## [Unreleased]
 
+## [3.8.1] — 2026-09-24
+
+### Upgrade notes
+
+- **Cassettes: no re-record needed.** Nothing in this release changes what a run declares or spawns for
+  any committed baseline: the proactive-mode fix resolves to the same value on every baseline it touches
+  (all from 1.46388.3 on already carry the gate on), and the other edits under `src/runtime`,
+  `src/hostloop`, `src/session.ts` and `baselines/` are comments, schema description text and one
+  baseline annotation string. `verify-cassettes examples/replays` reports all three committed cassettes
+  clean.
+- **Live-validated against `desktop-2.7032.0`**, which 3.8.0 shipped without. On agent 2.1.280, all four
+  tiers: `boundary-check` 6/6, e2e self-tests 9/9, `test:live` 19/20 on the first run, and
+  `run examples/scenarios/` 6/7. The `test:live` red was model variance in `live-matrix` (the model asked
+  in plain text instead of calling `AskUserQuestion`); the file passed on two re-runs. The seventh example,
+  `subagent-manifest-probe`, stopped when the operator account hit its usage limit and was not re-run.
+  Details in `DESIGN.md`'s scope note.
+
+### Fixed
+
+- **Proactive `suggest_skills` mode follows the Desktop version, not a gate Desktop no longer reads.**
+  From Desktop 1.46388.3 the asar has no reference to gate `1598976391` (`proactiveSkillSuggestEnabled`):
+  `suggest_skills` always carries the proactive description and `trigger` param when it is declared. The
+  server still serves the gate, and the harness read it for every baseline, so a server-side flip to off
+  would have switched proactive mode off here while production kept it on. For a baseline at 1.46388.3 or
+  later the row is now ignored and proactive mode is on; older baselines still read the gate, and
+  `skills.proactive_suggest_enabled` still overrides both. No change for any committed baseline: all of
+  them from 1.46388.3 on carry the gate on.
+
+### Documentation
+
+- **`docs/fidelity-gaps.md` — what the plugin-MCP shadow file carries depends on enforcement.** The page
+  said the whole rewritten server set goes into `cowork-plugin-mcp-shadow.json`. Read in the 2.7032.0
+  asar, that holds only when Desktop enforces remote shadowing (gate `2529235968` on and no enterprise
+  managed-configuration override); otherwise the file names only the remote servers a stand-in replaced,
+  policy stubs travel in the in-process SDK server map alone, and a failed write is logged rather than
+  refusing the session. The section also states that any failure building the stubs refuses the session
+  while an MCP policy is active, that a stub never appears as a `LocalMcpServerManager` connection, and
+  which `main.log` lines record the remote arm.
+- **Two pinned gate rows are records, not sentinels.** `canSaveSkill` (`3246569822`) has no reference in
+  any Desktop asar from 1.44121.1 on, and `proactiveSkillSuggestEnabled` (`1598976391`) none from
+  1.46388.3 on; the server still serves both, so `sync` keeps recording them. The gates `$comment` in the
+  2.7032.0 baseline, which `sync` carries forward, says so, and a flip of either row changes no run
+  against a current baseline.
+- **The unmodeled proactive skills-prompt line applies to every current session.** From Desktop 1.46388.3,
+  Desktop's generated `<skills_instructions>` block always carries its proactive suggestion guidance when
+  `suggest_skills` and `search_plugins` are available; the harness renders no such block, and
+  `docs/fidelity-gaps.md` states the gap at that scope. `skills.proactive_suggest_enabled: false` on such
+  a baseline builds a non-proactive `suggest_skills` that production does not ship there —
+  `docs/session.md`, the session schema's description and the companion skill's schema reference say so.
+
 ## [3.8.0] — 2026-09-22
 
 ### Upgrade notes

package/DESIGN.md

@@ -203,7 +203,7 @@ The policy that produces those `allow`/`deny` responses is the **Decider** seam
 > Cowork system-prompt fingerprint all unchanged from `1.20186.0`, with the staged VM ELF re-synced
 > 2.1.202 → 2.1.205 — and the live pass of that era was deliberately **not** restamped onto it.)
 
-> **Scope of that claim.** `2026-09-20 / desktop-2.2553.1` is the baseline carrying the latest live pass, and it was the newest committed baseline when that pass ran. **One baseline has shipped since (`2.7032.0`), one of which moved the agent ELF most recently to **2.1.280**.** **No live pass has been run against that newer baseline — it was skipped, not blocked.** The agent it pins (2.1.280) IS the staged one, so nothing prevented it; the decision was to ship the sync without re-running the suites. What the baseline rests on instead: a sync with zero unknown deltas, and a prompt-text change derived from the generator source of both asars rather than from a run. The pass below ran against the then-staged agent 2.1.275 (its VM ELF and the native `.app` both at that version) on macOS arm64, agent image `cowork-agent-base:2`, on harness **3.7.0**. It covered **all four** suites: `boundary-check` **6/6** (host-fs-sealed, direct-egress-denied, allowlist-enforced, allowlist-permits, loopback-not-proxied, hostloop-bash-egress); `npm run test:live` **4 files, 19 tests — 19 passed, 0 failed, 0 skipped**; the e2e self-tests **9/9 success** (canary-hostloop, smoke-askuserquestion, smoke-l1-container, smoke-l1-egress, smoke-l2-microvm, smoke-multiselect-deciderdir, smoke-multiselect, smoke-present-files, smoke-semantic-evidence-files); and `run examples/scenarios/` **7/7 success** on its first run (csv-fx-normalize, csv-metrics, example-pdf-skill, hostloop-computer-links, protocol-smoke, skill-loads, subagent-manifest-probe). **Zero skips** in the live lane is the part worth stating: every `describe` there is `skipIf`-gated on Docker, the staged-binary version and the token, so a gated case reports as SKIPPED rather than passing vacuously. `smoke-multiselect-deciderdir` runs the `--decider-llm` path, and `smoke-l2-microvm` passed in a real VM with its own kernel. Tiers exercised: **all four — `protocol`, `container`, `hostloop` and `microvm`**. Both credential paths were exercised: the `.env` OAuth token for the container/protocol tiers, and the agent's own macOS-Keychain self-sourcing at `hostloop`. **One fixture was repaired mid-pass, and the repair is the interesting part.** `smoke-semantic-evidence-files` failed twice with the same reasoning — its deliverable asked the agent to write a factual claim about a migration that never happened, and current models refuse to ship that unflagged. Fixture rot, not a regression: no commit had touched the file since v3.6.0 and its pass rate had already decayed to 56% over 9 runs. The payload now reports what the run itself did. Its falsifiability was re-verified rather than assumed — the unscoped twin still refuses with `evidence_incomplete` naming the dropped files, which is what makes the scoped form's green mean anything. **Scope-out, so this is not read as more than it is.** (a) A live pass verifies observed behaviour, not the whole spawn contract by construction. (b) These suites are model-dependent, so a single red is evidence of model variance until a re-run says otherwise — and the one red here was re-run, reproduced, and traced to the fixture rather than to the code. (c) The first `examples/scenarios/` run is the one counted; there was no second. Separately and not a live matter: all three committed cassettes in `examples/replays/` remain those re-recorded against `desktop-2.2553.1` on 2026-09-18; `verify-cassettes` exits 0 with all three clean and one accepted `unscanned` entry (`example-pdf-skill`'s uploaded artifact body, too large to commit). Re-stamp this paragraph, naming the baseline, whenever a live pass is actually re-run.
+> **Scope of that claim.** `2026-09-24 / desktop-2.7032.0` is the baseline carrying the latest live pass, run against agent **2.1.280**, and it is the newest committed baseline — no baselines have shipped since. The pass ran against the staged agent (its VM ELF and the native `.app` both at that version) on macOS arm64, agent image `cowork-agent-base:2`, on harness **3.8.1**. It covered **all four** suites: `boundary-check` **6/6** (host-fs-sealed, direct-egress-denied, allowlist-enforced, allowlist-permits, loopback-not-proxied, hostloop-bash-egress); `npm run test:live` **5 files, 20 tests — 19 passed, 1 failed, 0 skipped** on the first run; the e2e self-tests **9/9 success** (canary-hostloop, smoke-askuserquestion, smoke-l1-container, smoke-l1-egress, smoke-l2-microvm, smoke-multiselect-deciderdir, smoke-multiselect, smoke-present-files, smoke-semantic-evidence-files); and `run examples/scenarios/` **6/7 success** on its first run (csv-fx-normalize, csv-metrics, example-pdf-skill, hostloop-computer-links, protocol-smoke, skill-loads). **The two non-greens, stated rather than rounded away.** (1) The `test:live` red is `live-matrix`'s second cell (protocol tier, `desktop-1.18286.0`): the model asked its A-or-B question in plain text instead of calling `AskUserQuestion`, so the run ended on an unanswered question. The file then passed on two consecutive re-runs (2/2 each) — model variance, not a regression; nothing in this release touches the protocol tier or that baseline. (2) `subagent-manifest-probe` (hostloop) did not complete: the operator account's usage limit was reached mid-run, and the agent reported the limit instead of a result. That is a quota stop, not a verdict on the scenario; it was not re-run, and hostloop is still covered by `canary-hostloop` and `hostloop-computer-links`, both green. **Zero skips** in the live lane is the part worth stating: every `describe` there is `skipIf`-gated on Docker, the staged-binary version and the token, so a gated case reports as SKIPPED rather than passing vacuously. `smoke-multiselect-deciderdir` runs the `--decider-llm` path, and `smoke-l2-microvm` passed in a real VM with its own kernel. Tiers exercised: **all four — `protocol`, `container`, `hostloop` and `microvm`**. Both credential paths were exercised: the `.env` credentials for the container/protocol tiers, and the agent's own macOS-Keychain self-sourcing at `hostloop`. **Scope-out, so this is not read as more than it is.** (a) A live pass verifies observed behaviour, not the whole spawn contract by construction. (b) These suites are model-dependent, so a single red is evidence of model variance until a re-run says otherwise. (c) The first `examples/scenarios/` run is the one counted; there was no second. Separately and not a live matter: all three committed cassettes in `examples/replays/` are those re-recorded against `desktop-2.7032.0` on 2026-09-23; `verify-cassettes` exits 0 with all three clean and one accepted `unscanned` entry (`example-pdf-skill`'s uploaded artifact body, too large to commit). Re-stamp this paragraph, naming the baseline, whenever a live pass is actually re-run.
 
 > The staged agent ELF is unchanged (2.1.181) across the 1.14271.0→1.15200.0 asar bump, and 2.1.187 across the 1.15200.0→1.15962.0 bump. The live scenario suite (`protocol` + `container` tiers) was re-run against the 1.15200.0 baseline; the 1.15962.0 bump was verified via asar analysis (content byte-identical: host-loop generator, system prompt, identity string, gates, and egress domains all unchanged) plus a full local test suite pass. The 1.15962.1→1.17377.1 bump moved the staged agent to **2.1.197** and added `api.claude.ai` to the egress allowlist; re-verified via `sync` (no unknown deltas) plus a manual asar spot-check of the reconstructed prompt content (substantively unchanged — see the Parity entry in CHANGELOG.md) and a full live scenario-suite pass (`protocol` + `container` tiers).
 

package/README.md

@@ -36,7 +36,7 @@ npm ci && npm run build
 node dist/cli.js replay examples/replays/example-pdf-skill.cassette.json
 ```
 
-(Installing globally — `npm install -g "cowork-harness@^3.8.0"` — gives you the `cowork-harness` CLI for your own
+(Installing globally — `npm install -g "cowork-harness@^3.8.1"` — gives you the `cowork-harness` CLI for your own
 scenarios and cassettes; the bundled example above also replays from a global install — see the `$(npm root -g)` path below.)
 
 Full setup → [Quick start](./docs/cli.md#quick-start).
@@ -49,8 +49,8 @@ Three ways to use this project. Each row is the whole hook — follow the link f
 
 | I want to… | Start here | Needs |
 |---|---|---|
-| **Run scenarios myself** from a terminal | **[docs/cli.md](./docs/cli.md)**<br><br>`npm i -g "cowork-harness@^3.8.0"`<br>`cowork-harness replay examples/replays/example-pdf-skill.cassette.json` | Node ≥ 22. The replay demo above is token-free and needs nothing else; live tiers above `protocol` need Docker + a staged agent binary |
-| **Have Claude Code drive it** for me | **[docs/companion-skill.md](./docs/companion-skill.md)**<br><br>`/plugin marketplace add yaniv-golan/cowork-harness`<br>`/plugin install cowork-harness@cowork-harness` | Claude Code. The skill self-bootstraps the CLI via `npx "cowork-harness@^3.8.0"` |
+| **Run scenarios myself** from a terminal | **[docs/cli.md](./docs/cli.md)**<br><br>`npm i -g "cowork-harness@^3.8.1"`<br>`cowork-harness replay examples/replays/example-pdf-skill.cassette.json` | Node ≥ 22. The replay demo above is token-free and needs nothing else; live tiers above `protocol` need Docker + a staged agent binary |
+| **Have Claude Code drive it** for me | **[docs/companion-skill.md](./docs/companion-skill.md)**<br><br>`/plugin marketplace add yaniv-golan/cowork-harness`<br>`/plugin install cowork-harness@cowork-harness` | Claude Code. The skill self-bootstraps the CLI via `npx "cowork-harness@^3.8.1"` |
 | **Gate my skill in CI** | **[docs/ci.md](./docs/ci.md)**<br><br>`- uses: yaniv-golan/cowork-harness@v3`<br>`  with: { command: replay, path: cassettes/ }` | Nothing for the token-free gate; the live lane needs a self-hosted runner with Docker + an agent binary |
 
 Not sure a harness is what you need? The next two sections are the argument.

package/baselines/desktop-2.7032.0.json

@@ -348,7 +348,7 @@
     "asarPath": "/Applications/Claude.app/Contents/Resources/app.asar",
     "asarFingerprint": "7c4da429c2aae02c",
     "gates": {
-      "$comment": "Production GrowthBook gate states decoded from ~/Library/Application Support/Claude/fcache (standard interactive Anthropic account, 2026-06-13; binary-verified app.asar 1.12603.1). Pin per release. Behavior-affecting gates the harness models: 1143815894 (loop), 1648655587 (dispatch cap), 1978029737 (web_fetch routing). Telemetry/auth-internal gates omitted. Also pinned: 2614807392 (skeletonHome), 123929380 (autoMemoryStandardSessions), 1696890383 (memoryGuidelinesEnv), 2860753854 (memoryExtraGuidelines) — dormant drift-sentinels for dark-launched features (host-fs skeleton, auto-memory) the harness deliberately models as OFF (or, for memoryExtraGuidelines, as inert-default: on in production but its served value equals the hardcoded default); pinned so a production flip surfaces as a sync diff instead of silent drift. The skill-family gates are pinned on the same principle but are NOT all dormant: 245679952 (suggestSkillsEnabled) and 1598976391 (proactiveSkillSuggestEnabled) ARE modeled — they gate the skills SDK-MCP tool surface. 3246569822 (canSaveSkill) is served ON/force by a server-side rollout (independent of Desktop version) and is deliberately NOT modeled: ON adds an mcp__cowork__save_skill tool and changes the skills system prompt, so this pin records a known fidelity gap rather than a modeled surface — see docs/fidelity-gaps.md. 1824824999 (canProposeSkills) is present-but-off, pinned so the same class of silent widening cannot land unnoticed. 1598976391 (proactiveSkillSuggestEnabled) flipped off/defaultValue -> ON/force by a SERVER-SIDE rollout observed 2026-08-04 — NOT a Desktop change: the gate id occurs exactly once in both the 1.24012.9 and 1.24012.11 asars and would read ON on .9 today, so this value is Desktop-version-INDEPENDENT despite living in a version-named file (same provenance class as canSaveSkill above). It is read from a SINGLE account's fcache; force rules are server-evaluated and can be segment-targeted, so whether the rollout is global is not determinable from anything on disk. Unlike canSaveSkill this one IS modeled (both branches exist), so the pin changes the emulated suggest_skills surface: proactive description + an optional trigger param + a chained empty-catalog note. Override per-session with skills.proactive_suggest_enabled. 4074604942 (1p-direct-mcp) was NEW in 1.24012.11 and DARK (absent from a standard fcache, hence its DARK_GATES entry); it arms a Desktop-side direct-MCP pool for MDM-managed 1P servers, inert for an unmanaged account, pinned as a sentinel only. Observed 2026-08-05 SERVED rather than absent (source \"force\", value false) — the rollout reached this account with the gate OFF, so nothing it arms is reachable and no modeled surface changes. Same provenance class as canSaveSkill: read from a SINGLE account's fcache, and force rules are server-evaluated and segment-targetable, so its DARK_GATES entry is retained deliberately — another account may still see it absent, and that must stay tolerated rather than hard-failing their sync.",
+      "$comment": "Production GrowthBook gate states decoded from ~/Library/Application Support/Claude/fcache (standard interactive Anthropic account, 2026-06-13; binary-verified app.asar 1.12603.1). Pin per release. Behavior-affecting gates the harness models: 1143815894 (loop), 1648655587 (dispatch cap), 1978029737 (web_fetch routing). Telemetry/auth-internal gates omitted. Also pinned: 2614807392 (skeletonHome), 123929380 (autoMemoryStandardSessions), 1696890383 (memoryGuidelinesEnv), 2860753854 (memoryExtraGuidelines) — dormant drift-sentinels for dark-launched features (host-fs skeleton, auto-memory) the harness deliberately models as OFF (or, for memoryExtraGuidelines, as inert-default: on in production but its served value equals the hardcoded default); pinned so a production flip surfaces as a sync diff instead of silent drift. The skill-family gates are pinned on the same principle but are NOT all dormant: 245679952 (suggestSkillsEnabled) is modeled — it gates whether suggest_skills is declared. 3246569822 (canSaveSkill) is DEAD in Desktop code from 1.44121.1 (0 occurrences in every asar from 1.44121.1 through this one) although the fcache still serves it ON/force: its row is a record of what the server sends, not a sentinel, and a flip of it changes nothing. The mcp__cowork__save_skill tool it once gated is present in real sessions and is not modeled — see docs/fidelity-gaps.md. 1824824999 (canProposeSkills) is present-but-off, pinned so the same class of silent widening cannot land unnoticed. 1598976391 (proactiveSkillSuggestEnabled) flipped off/defaultValue -> ON/force by a SERVER-SIDE rollout observed 2026-08-04 — NOT a Desktop change: the gate id occurs exactly once in both the 1.24012.9 and 1.24012.11 asars and would read ON on .9 today, so this value is Desktop-version-INDEPENDENT despite living in a version-named file (same provenance class as canSaveSkill above). It is read from a SINGLE account's fcache; force rules are server-evaluated and can be segment-targeted, so whether the rollout is global is not determinable from anything on disk. Like canSaveSkill, this id is DEAD in Desktop code: 0 occurrences in every asar from 1.46388.3 through this one, where the proactive suggest_skills description and the trigger param are unconditional whenever suggest_skills is declared. The harness reads this row only for a baseline older than 1.46388.3; from there proactive mode is always on, as in production, so a flip of this row does not change a run. Override per-session with skills.proactive_suggest_enabled. 4074604942 (1p-direct-mcp) was NEW in 1.24012.11 and DARK (absent from a standard fcache, hence its DARK_GATES entry); it arms a Desktop-side direct-MCP pool for MDM-managed 1P servers, inert for an unmanaged account, pinned as a sentinel only. Observed 2026-08-05 SERVED rather than absent (source \"force\", value false) — the rollout reached this account with the gate OFF, so nothing it arms is reachable and no modeled surface changes. Same provenance class as canSaveSkill: read from a SINGLE account's fcache, and force rules are server-evaluated and segment-targetable, so its DARK_GATES entry is retained deliberately — another account may still see it absent, and that must stay tolerated rather than hard-failing their sync.",
       "emitToolUseSummaries:66187241": {
         "on": false,
         "source": "defaultValue",

package/dist/loop-decision.js

@@ -1,3 +1,4 @@
+import { cmpVersionStrings } from "./baseline.js";
 /**
  * Read a GrowthBook gate sub-flag (e.g. `coworkWebFetchPrompt`) from the baseline's `provenance.gates`.
  *
@@ -129,13 +130,33 @@ export function readGateBool(baseline, id) {
  *
  * Defaults when the gate is absent from the baseline: `suggestSkills` → true, `proactiveSuggest` → false
  * (the documented production state).
+ *
+ * Proactive mode is version-dependent. Up to Desktop 1.44121.1 it is gate `1598976391`. From
+ * {@link PROACTIVE_SUGGEST_UNCONDITIONAL_FROM} the gate id is gone from the asar and `suggest_skills` always
+ * carries the proactive description and `trigger` param whenever it is declared — so for those baselines
+ * the gate row is IGNORED even though the fcache still serves it. Reading it there would let a server-side
+ * flip of a gate Desktop no longer reads turn the harness's proactive mode off while production keeps it on.
+ * The session knob still wins either way.
  */
 export function resolveSkillDiscoveryGates(baseline, knobs = {}) {
     return {
         suggestSkillsEnabled: knobs.suggest_enabled ?? readGateBool(baseline, "245679952") ?? true,
-        proactiveSkillSuggestEnabled: knobs.proactive_suggest_enabled ?? readGateBool(baseline, "1598976391") ?? false,
+        proactiveSkillSuggestEnabled: knobs.proactive_suggest_enabled ?? proactiveFromBaseline(baseline),
     };
 }
+/** First backed-up Desktop build whose asar has no reference to gate `1598976391` (0 occurrences from
+ *  here through 2.7032.0; 2 in 1.44121.1, the previous backup — builds in between are unobserved, and a
+ *  baseline for one would take the gate path, the conservative side). From this build proactive suggest
+ *  mode is unconditional. */
+export const PROACTIVE_SUGGEST_UNCONDITIONAL_FROM = "1.46388.3";
+function proactiveFromBaseline(baseline) {
+    // `appVersion` is required by the schema, but synthetic test baselines omit it; a missing version
+    // compares as 0.0.0 and takes the gate path, which is the pre-1.46388.3 behaviour.
+    const v = baseline.appVersion;
+    if (typeof v === "string" && cmpVersionStrings(v, PROACTIVE_SUGGEST_UNCONDITIONAL_FROM) >= 0)
+        return true;
+    return readGateBool(baseline, "1598976391") ?? false;
+}
 export function decideLoop(inputs) {
     if (inputs.requireFullVmSandbox === true)
         return "vm"; // HeA()

package/dist/session.js

@@ -142,9 +142,10 @@ export const SessionConfig = z.strictObject({
             .optional()
             .describe("override for gate 1598976391 (proactiveSkillSuggestEnabled): when true (and suggest_enabled is not " +
             "false), suggest_skills swaps to the proactive description, gains an optional `trigger` enum param, " +
-            "and chains its empty-catalog note into search_plugins. Omit to use the synced baseline gate — on " +
-            "from the 1.24012.11 baseline, matching what production serves; the fallback for a baseline that " +
-            "predates the gate is false."),
+            "and chains its empty-catalog note into search_plugins. Omit to follow the baseline: from the 1.46388.3 " +
+            "baseline Desktop does not read the gate and proactive mode is always on; for an older baseline the " +
+            "synced gate decides (on from 1.24012.11; false for a baseline that predates the gate). On a 1.46388.3+ " +
+            "baseline, false builds a non-proactive surface production does not ship there."),
     })
         .default({ local: [] }),
     mcp: z

package/dist/sync/cowork-sync.js

@@ -108,24 +108,38 @@ export const PINNED_GATES = {
     // init.tools of 8 real sessions) render, and in what mode. None was pinned before, so 245679952
     // being live on/force was invisible to the drift guard. Present in the live fcache (NOT dark), so
     // they are read at their real state — no DARK_GATES entry. BEHAVIORALLY MODELED since A2: the harness
-    // declares the skills/plugins SDK-MCP servers and reads BOTH gates at spawn
-    // (`resolveSkillDiscoveryGates`), so a flip here CHANGES the declared tool set on container/hostloop
-    // (see `src/hostloop/skills-handler.ts`) — it is NOT inert. A pinned drift alone WARNS + still writes.
+    // declares the skills/plugins SDK-MCP servers and reads 245679952 at spawn (`resolveSkillDiscoveryGates`),
+    // so a flip of it CHANGES the declared tool set on container/hostloop (see
+    // `src/hostloop/skills-handler.ts`) — it is NOT inert. 1598976391 is read only for a baseline older than
+    // 1.46388.3 (see its entry below). A pinned drift alone WARNS + still writes.
     "245679952": "suggestSkillsEnabled", // live on/force — gates whether suggest_skills renders at all
-    // proactive (unprompted) suggest mode. (A prior note speculated this widens at agent >=2.1.217 to gate
-    // the whole discovery-tool family; REFUTED — 2.1.205-2.1.217 sessions carry the full skills family with
-    // this gate OFF.) It has THREE effects, not two: it swaps suggest_skills's description, adds `trigger`,
-    // AND is passed into generateSkillsSystemPrompt, where it swaps the suggest-guidance line inside the
-    // dynamically-generated `<skills_instructions>` block (plus a once-per-conversation sentence). A prior
-    // version of this comment claimed "only swaps the description and adds `trigger`" — that was wrong about
-    // the product. The harness models the first two and renders no `<skills_instructions>` section at all,
-    // so the prompt effect is a disclosed gap, not a modelled surface (same shape as canSaveSkill below).
+    // proactive (unprompted) suggest mode. DEAD IN DESKTOP CODE FROM 1.46388.3: 2 occurrences in the 1.40609.1
+    // and 1.44121.1 asars, 0 in every asar from 1.46388.3 through 2.7032.0, and the `proactiveSkillSuggestEnabled`
+    // name is gone too. From that build Desktop gives suggest_skills its proactive description and `trigger`
+    // param unconditionally whenever the tool is declared. Up to 1.44121.1 the gate was live, with three effects:
+    // the description swap, `trigger`, and a swapped suggest-guidance line in the generated
+    // `<skills_instructions>` block (a prompt effect the harness never models).
+    // The harness reads this row at spawn ONLY for a baseline older than 1.46388.3; from there
+    // `resolveSkillDiscoveryGates` ignores it and proactive mode is always on, as in production. So a
+    // server-side flip here is a sync diff with no effect on runs against a current baseline. Like
+    // canSaveSkill below, the row is a record of what the server sends, not a sentinel.
     "1598976391": "proactiveSkillSuggestEnabled",
-    // Flipped off/defaultValue -> ON/force server-side (fcache) as of 2026-07-25, i.e. for current users on
-    // any Desktop version — NOT a Desktop change; the machinery already shipped in 1.24012.1 gated off. ON
-    // adds a `save_skill` tool to the session's SDK-MCP inventory AND is passed into
-    // generateSkillsSystemPrompt, so it changes both the tool set and the skills prompt. The harness models
-    // NEITHER yet, so this is a known fidelity gap, not a modelled surface.
+    // DEAD IN DESKTOP CODE SINCE 1.44121.1 — THIS PIN PROVIDES NO COVERAGE OF `save_skill`. The id has 3
+    // occurrences in the 1.40609.1 asar and 0 in every asar from 1.44121.1 through 2.7032.0 (count with
+    // `grep -ao <id> app.asar | wc -l`; `grep -c` counts lines of a minified file and undercounts). The
+    // fcache still serves it on/force, so sync round-trips it and reports "no change": a green light on a
+    // disconnected sensor. Up to 1.40609.1 the gate was live, and its off -> on flip on 2026-07-25 is what
+    // put `mcp__cowork__save_skill` into real sessions. The row is kept only as a record of what the server
+    // sends: baselines from 1.24012.1 on carry it (from 1.44121.1 on with a `note` saying it is unread), and
+    // docs/fidelity-gaps.md names it. Do not read it as a tripwire.
+    // At 2.7032.0 the tool follows `skillsEnabled`, the managed `skillCreationEnabled` setting and two gates
+    // that first appear in that build: 3656976882 (org skills off) and 3469616823 (bypass for the org skill-
+    // creation block). The org check reads a `skill_creation` status from an account access list Desktop
+    // fetches at runtime (`/api/bootstrap/<org>/current_user_access`, held in memory, absent from the fcache)
+    // and can only turn the tool OFF — an unloaded list allows it. Pinning the two newer gates would NOT make
+    // this a sentinel: the access list sits outside the fcache. The observable outcome is whether a REAL
+    // Desktop session's init tool list carries `mcp__cowork__save_skill` — never a harness run's, which lists
+    // only what the harness itself declares and does not declare `save_skill` at any tier.
     "3246569822": "canSaveSkill",
     // off/defaultValue and PRESENT in the fcache (so NOT dark — no DARK_GATES entry) — the `propose_skills`
     // render-only sibling. Pinned so a production flip surfaces as a sync diff instead of silently widening

package/docs/ci.md

@@ -107,7 +107,7 @@ jobs:
           anthropic-api-key: ${{ secrets.ANTHROPIC_API_KEY }}
 ```
 
-Every run writes a Markdown verdict table (scenario, pass/fail, signals, cost/turns when available, staleness findings, and the replay-skipped-assertions honesty line) to the job summary. Inputs: `command`, `path` (required), `version` (npm dist-tag/version, default `latest` — the recipes above pin `^3` instead, because leaving it at `latest` takes a CLI major the moment it is promoted even though your `uses:` ref never changed; pin an exact version for byte-reproducible CI. The companion skill's `cowork-harness@^3.8.0` floor guidance applies to ad-hoc CLI installs, not this input), `strict` (applies to `replay` (staleness findings), `lint`/`lint-skill` (WARN/INFO), and `analyze-skill` (any **`error`**-severity finding — advisory findings are precisely the class that does NOT gate); IGNORED — not forwarded — for `verify-cassettes`/`run`, which don't accept the flag), `fail-on-skill-drift` (**`replay`-only** — never forwarded to the analyzers), `extra-args`, `summary` (default `true`), `anthropic-api-key` (live lane only). Outputs: `ok` (`"true"`/`"false"`, mirrors the exit code), `envelope-path` (path to the raw JSON envelope, for post-processing), `summary-md` (the rendered verdict table, exposed as an output — not just written to `$GITHUB_STEP_SUMMARY` — because that file is scoped to this action's own invocation and a caller's later step gets a fresh, empty one). See [`action.yml`](https://github.com/yaniv-golan/cowork-harness/blob/main/action.yml) for the full input/output reference.
+Every run writes a Markdown verdict table (scenario, pass/fail, signals, cost/turns when available, staleness findings, and the replay-skipped-assertions honesty line) to the job summary. Inputs: `command`, `path` (required), `version` (npm dist-tag/version, default `latest` — the recipes above pin `^3` instead, because leaving it at `latest` takes a CLI major the moment it is promoted even though your `uses:` ref never changed; pin an exact version for byte-reproducible CI. The companion skill's `cowork-harness@^3.8.1` floor guidance applies to ad-hoc CLI installs, not this input), `strict` (applies to `replay` (staleness findings), `lint`/`lint-skill` (WARN/INFO), and `analyze-skill` (any **`error`**-severity finding — advisory findings are precisely the class that does NOT gate); IGNORED — not forwarded — for `verify-cassettes`/`run`, which don't accept the flag), `fail-on-skill-drift` (**`replay`-only** — never forwarded to the analyzers), `extra-args`, `summary` (default `true`), `anthropic-api-key` (live lane only). Outputs: `ok` (`"true"`/`"false"`, mirrors the exit code), `envelope-path` (path to the raw JSON envelope, for post-processing), `summary-md` (the rendered verdict table, exposed as an output — not just written to `$GITHUB_STEP_SUMMARY` — because that file is scoped to this action's own invocation and a caller's later step gets a fresh, empty one). See [`action.yml`](https://github.com/yaniv-golan/cowork-harness/blob/main/action.yml) for the full input/output reference.
 
 CI uses `ANTHROPIC_API_KEY` specifically because there's no interactive browser available to run
 `claude setup-token`'s OAuth flow in a GitHub Actions runner; locally, the OAuth token is preferred because

package/docs/cli.md

@@ -18,7 +18,7 @@ companion skill, CI). This page is the CLI one.
 **Install from npm:**
 
 ```bash
-npm install -g "cowork-harness@^3.8.0"    # puts the `cowork-harness` command on your PATH
+npm install -g "cowork-harness@^3.8.1"    # puts the `cowork-harness` command on your PATH
 ```
 
 **Or build from source:**
@@ -38,7 +38,7 @@ node dist/cli.js replay examples/replays/example-pdf-skill.cassette.json
 
 > **Installed globally instead?** Once linked/installed, the same command is `cowork-harness replay
 > <cassette>` — but the relative path above only resolves from a source checkout's `examples/replays/`.
-> From a global install (`npm i -g "cowork-harness@^3.8.0"`), point at the package root instead:
+> From a global install (`npm i -g "cowork-harness@^3.8.1"`), point at the package root instead:
 > `cowork-harness replay "$(npm root -g)/cowork-harness/examples/replays/example-pdf-skill.cassette.json"`
 > (or copy the cassette into your own project and pass that path).
 
@@ -48,7 +48,7 @@ Live `run`/`skill` need the prerequisites in the next section — note the `prot
 > - **Replay only (zero setup):** `cowork-harness replay <cassette>` — no token, no Docker, no agent. The command above.
 > - **`protocol` (real model, no Docker):** needs only the auth token (item 3 below).
 > - **Live `container` / `microvm` / `hostloop` / `cowork`:** needs Docker (or Lima for `microvm`), a staged agent, and the token — run `cowork-harness doctor` first.
-> - **Invocation:** from a source checkout, `node dist/cli.js <cmd>` (or `npm link` to get the `cowork-harness` command); from a global install, `cowork-harness <cmd>`; the companion skill falls back to `npx "cowork-harness@^3.8.0"`.
+> - **Invocation:** from a source checkout, `node dist/cli.js <cmd>` (or `npm link` to get the `cowork-harness` command); from a global install, `cowork-harness <cmd>`; the companion skill falls back to `npx "cowork-harness@^3.8.1"`.
 
 Two more worked examples worth knowing about: `examples/scenarios/protocol-smoke.yaml` (zero-Docker smoke
 test) and `examples/scenarios/skill-loads.yaml` (container-tier acceptance check) — see
@@ -124,7 +124,7 @@ The parts people ask about. **`package.json`'s `files[]` is the exhaustive, mach
 this table is the readable summary of it, and deliberately omits the infrastructure that always ships
 (`baselines/`, `schema/`, `fixtures/`, `scripts/`, `docker/`).
 
-| What ships | npm global (`npm install -g "cowork-harness@^3.8.0"`) | Source checkout (`git clone` + `npm ci`) |
+| What ships | npm global (`npm install -g "cowork-harness@^3.8.1"`) | Source checkout (`git clone` + `npm ci`) |
 |---|---|---|
 | CLI, `scenario.py` + assertion keys (enough for `lint` in CI) | ✓ | ✓ |
 | `SKILL.md`, all of `docs/`, `SPEC.md`/`DESIGN.md`/`AGENTS.md` | ✓ | ✓ |
@@ -139,7 +139,7 @@ since a global install puts nothing in your working directory. The matrix, answe
 examples are the only ones that still need a source checkout. The **marketplace skill install** is
 narrower again — it pulls only `.claude/skills/cowork-harness/` (SKILL.md + `references/` +
 `scenario.py`/assertion keys, per `.claude-plugin/marketplace.json`'s `source`); everything in the npm column
-arrives when the skill's first command self-bootstraps `npx "cowork-harness@^3.8.0"` — the last row stays
+arrives when the skill's first command self-bootstraps `npx "cowork-harness@^3.8.1"` — the last row stays
 ✗ either way, since `matrices/`, `answer-policies/` and `probes/` are not published at all. See
 [docs/companion-skill.md](./companion-skill.md) for that install path.
 

package/docs/companion-skill.md

@@ -28,7 +28,7 @@ claude plugin marketplace add yaniv-golan/cowork-harness
 claude plugin install cowork-harness@cowork-harness
 ```
 
-The skill **self-bootstraps the CLI**: if `cowork-harness` isn't on your PATH it falls back to `npx "cowork-harness@^3.8.0"` (a version floor that fails loud rather than silently fetching a too-old CLI; Node ≥ 22). Tiers above `protocol` still need Docker/Lima and a Claude Desktop agent binary — see the prerequisites below.
+The skill **self-bootstraps the CLI**: if `cowork-harness` isn't on your PATH it falls back to `npx "cowork-harness@^3.8.1"` (a version floor that fails loud rather than silently fetching a too-old CLI; Node ≥ 22). Tiers above `protocol` still need Docker/Lima and a Claude Desktop agent binary — see the prerequisites below.
 
 It also follows the open [Agent Skills](https://agentskills.io) spec, so it installs cross-editor (Cursor, Codex, OpenCode, …) via [`npx skills`](https://github.com/vercel-labs/skills) (Vercel Labs' CLI implementation of that spec):
 
@@ -41,7 +41,7 @@ npx skills add yaniv-golan/cowork-harness --skill cowork-harness
 **What the marketplace install actually pulls:** only `.claude/skills/cowork-harness/` — SKILL.md +
 `references/` + `scenario.py`/assertion keys, per `.claude-plugin/marketplace.json`'s `source`. Everything
 else (the CLI, `docs/`, the worked examples, the pytest lane) arrives when the skill's first command
-self-bootstraps `npx "cowork-harness@^3.8.0"`, which pulls the same npm package as a global install.
+self-bootstraps `npx "cowork-harness@^3.8.1"`, which pulls the same npm package as a global install.
 
 For the full package-contents table — what a global install gives you versus a source checkout — see
 [docs/cli.md → What ships](./cli.md#what-ships). It is maintained there, once.

package/docs/fidelity-gaps.md

@@ -327,7 +327,7 @@ ordinary session**:
   session shadows remote servers at all (gate `2529235968`, or at least one third-party direct MCP server
   present) **and** a stand-in already provides that server, matched by URL hostname or by name. The
   stand-ins are the session's claude.ai connectors that carry at least one enabled tool, plus those direct
-  servers. Logged *"Plugin `<name>` declares remote MCP servers (…). Overriding with no-ops so the CLI does
+  servers. Logged *"Plugin `<id>` declares remote MCP servers (…). Overriding with no-ops so the CLI does
   not open its own client."* With the gate off and no such server, the remote arm never runs, and a
   plugin's remote servers reach the CLI intact. Earlier builds (1.37937.0 through 1.46388.x) stubbed
   **every** remote plugin server once the gate was on; the stand-in narrowing arrives with 2.2553.1.
@@ -339,9 +339,28 @@ A plugin Desktop treats as official is exempt from both arms unless a policy is
 
 A replaced server is renamed `plugin:<pluginName>:<serverName>` and constructed as
 `createSdkMcpServer({name, tools: []})` — **the server name is present in the session's inventory and offers
-zero tools.** The rewritten set is written to `cowork-plugin-mcp-shadow.json` and delivered to the agent as
-an `--mcp-config` payload; when the session shadows remote servers *and* an MCP policy is active, a failed
-delivery makes Desktop refuse to start the session rather than launch with unenforced plugin servers.
+zero tools.** Every stub reaches the agent in Desktop's in-process SDK server map. Which stubs are _also_
+named in `cowork-plugin-mcp-shadow.json`, delivered as an `--mcp-config` payload, depends on whether
+Desktop enforces remote shadowing for the session: gate `2529235968` on **and** no enterprise
+managed-configuration override in force. When it does, the file names every replaced server, policy stubs
+included. When it does not, the file names only the remote servers a stand-in replaced, and a session with
+none writes no file at all; local and `.mcpb` policy stubs then travel in the SDK map alone.
+
+While an MCP policy is active, Desktop refuses to start the session rather than launch with unenforced
+plugin servers whenever building the overrides fails, whatever the gate: a failed plugin scan (*"Plugin MCP
+scan failed while an MCP policy is active"*) or any other error in that step. It also refuses when the
+shadow file cannot be written, but only while it enforces remote shadowing; otherwise a failed write is
+logged and the spawn goes ahead without the file.
+
+Desktop's own MCP pool, `LocalMcpServerManager`, takes only a plugin's local stdio and `.mcpb` servers, and
+skips any a policy blocks. Remote plugin servers that no stand-in replaced are left for the CLI to open
+itself. **A stub therefore never appears as a `LocalMcpServerManager` connection**, which makes Desktop's
+`main.log` an unambiguous record of the remote arm: each replacement logs
+`Replacing plugin "<plugin>" MCP server "<server>": "<connector>" already provides it (matched by url)`,
+then `Plugin "<id>" declares remote MCP servers (…). Overriding with no-ops …`. On a Desktop whose
+connected Slack, Notion or Airtable connector matches a plugin's declared server by URL, both lines appear
+for every session that loads the plugin, and the plugin servers that connect through
+`LocalMcpServerManager` are only local stdio ones.
 
 **What the harness does:** nothing. Plugins are staged with `--plugin-dir` and the CLI reads each plugin's
 own declaration, so a plugin under test gets **working** MCP servers with their real tools.
@@ -852,19 +871,23 @@ over the control protocol (`sdkMcpServers` in `initialize`, tunneled as `mcp_mes
 `list_skills` returns no match, and the result renders an "Add" card. The call has **no side effect**
 (nothing installs; the user's Add click happens out of band). Ground truth: these tools appear in the
 `system/init` `tools` array of real on-disk sessions (`local-agent-mode-sessions/**/audit.jsonl`); the
-`suggestSkillsEnabled` gate `245679952` is on. A proactive-suggestion mode sits behind a second gate
-`1598976391` (`proactiveSkillSuggestEnabled`), which is **served ON** for a standard account as of the
-`1.24012.11` baseline — by a server-side rollout, not a Desktop change (the gate reads ON on earlier
-Desktop versions too). With it off, `suggest_skills` keeps its base description and the model suggests
-only when the conversation invites it. With it on, the tool gains an optional `trigger` parameter
+`suggestSkillsEnabled` gate `245679952` is on. `suggest_skills` also has a proactive-suggestion mode.
+From Desktop `1.46388.3` (the first backed-up build after `1.44121.1`) that mode is **unconditional** whenever `suggest_skills` is declared: no gate
+is read for it. Up to `1.44121.1` it sits behind gate `1598976391`
+(`proactiveSkillSuggestEnabled`), which the server serves **on** for a standard account from the
+`1.24012.11` baseline; the server still serves that gate, but Desktop from `1.46388.3` never reads it.
+With the mode off, `suggest_skills` keeps its base description and the model suggests only when the
+conversation invites it. With it on, the tool gains an optional `trigger` parameter
 (`user_asked` | `proactive`), a proactive description that also carries production's *constraints* (a
 do-not-call list, a suggest-at-most-once-per-conversation rule, a no-lead-in rule, and forwarding the
 same keywords **and trigger** to `search_plugins`), and an empty-catalog `note` that chains into
 `search_plugins` for every trigger state — silence is only the `proactive` tail, and a trigger the model
-never supplied is never forwarded back to it. One production effect is **not** modeled: the flag is also
-passed into Desktop's `generateSkillsSystemPrompt`, where it swaps a guidance line inside the generated
-`<skills_instructions>` block. The harness renders no such section at all, so that effect lands in an
-already-unmodeled surface.
+never supplied is never forwarded back to it. One production effect is **not** modeled: a proactive
+suggest-guidance line (with a suggest-at-most-once-per-conversation sentence) inside the generated
+`<skills_instructions>` block. Up to `1.44121.1` the gate selects it; from `1.46388.3` Desktop emits it
+whenever `suggest_skills` and `search_plugins` are available, so on a current baseline this gap applies to
+every session that declares `suggest_skills`. The harness renders no such section at all, so the effect
+lands in an already-unmodeled surface.
 
 **Harness behaviour:** `container` and `hostloop` (and `cowork`, which resolves to one of those) now
 declare a `skills` and a `plugins` SDK-MCP server alongside `cowork`/`workspace` (`combineSdkMcp`,
@@ -878,9 +901,11 @@ synced baseline (`readGateBool`, bare-boolean shape — distinct from the sub-fl
 reads) with a session-level override (`skills.suggest_enabled` / `skills.proactive_suggest_enabled`, see
 [session.md](./session.md)). Precedence is knob ▸ baseline gate ▸ hardcoded fallback, and the three are
 distinct: omit the knob and the value comes from the **synced baseline** (on `latest` that is
-`suggestSkillsEnabled` on and `proactiveSkillSuggestEnabled` **on**, mirroring what production serves);
-the hardcoded fallback, which applies only to a baseline old enough to predate the gate entirely, stays
-on for `suggestSkillsEnabled` and **off** for `proactiveSkillSuggestEnabled`.
+`suggestSkillsEnabled` on); the hardcoded fallback, which applies only to a baseline old enough to predate
+the gate entirely, is on. Proactive mode follows the Desktop version the same way production does: from
+the `1.46388.3` baseline it is **always on** and the `1598976391` row is ignored, so a server-side flip of
+a gate Desktop does not read cannot change a run; for an older baseline the synced gate decides, with a
+hardcoded fallback of **off** for a baseline that predates it.
 
 **How exact is the model?** Not uniformly — and the difference matters, so it is stated plainly. The
 tool **inventory** (which five tools exist), their **inputSchemas**, the **gating** semantics, and the

package/docs/session.md

@@ -95,11 +95,11 @@ plugins:
 skills:
   local: []                      # extra host skill dirs → CLAUDE_CONFIG_DIR/skills
   # Overrides for the skill-discovery SDK-MCP gates (container/hostloop only — see fidelity-gaps.md
-  # "Skill/plugin discovery SDK-MCP servers"). Precedence: this knob → the synced baseline gate → the
-  # documented default. Both omit-able; the harness resolves gate 245679952/1598976391 from the baseline
-  # when unset.
+  # "Skill/plugin discovery SDK-MCP servers"). Precedence: this knob → the baseline → the documented
+  # default. Both omit-able; unset, suggest_enabled follows gate 245679952, and proactive_suggest_enabled is
+  # always on from the 1.46388.3 baseline and follows gate 1598976391 before it.
   suggest_enabled: true          # gate 245679952 (suggestSkillsEnabled) override; default true when unset
-  proactive_suggest_enabled: false # gate 1598976391 (proactiveSkillSuggestEnabled) override; unset = the synced baseline gate (ON from 1.24012.11)
+  proactive_suggest_enabled: false # gate 1598976391 (proactiveSkillSuggestEnabled) override; unset = always on from the 1.46388.3 baseline, the synced gate before it
 mcp:
   config: null                   # --mcp-config file (standard mcpServers map), e.g. ../data/mcp.json
   enabled: []                    # enabledMcpjsonServers
@@ -229,7 +229,7 @@ See [discovery.md](./discovery.md) for the full model. In short: the harness bui
 | `plugins.local_plugins[]` / `remote_plugins[]` | Cowork plugin mounts | → `mnt/.local-plugins/marketplaces/<marketplace>/<plugin>` (≥1.14271.0; older baselines use `.local-plugins/cache`) / `mnt/.remote-plugins/plugin_<id>` (migrated-Cowork uploaded/org-remote shape; the id is a stable hash of the declared source). A skill that references these via `${CLAUDE_PLUGIN_ROOT}` must mind [the two-namespace resolution model](./plugin-root.md) — the token is unset in host-loop VM bash. |
 | `skills.local[]` | `CLAUDE_CONFIG_DIR/skills` | extra host **skill** dirs (a folder *without* `.claude-plugin/plugin.json`) staged into the config dir's `skills/`. Use this for a single-skill folder; use `plugins.local_plugins` for a plugin root. |
 | `skills.suggest_enabled` | gate `245679952` (`suggestSkillsEnabled`) override | `container`/`hostloop` (and `cowork`) only. `true` (or unset, if the synced baseline gate is on/absent) declares the `skills` SDK-MCP server's `suggest_skills` tool; `false` omits it and drops `list_skills`' fallback-to-`suggest_skills` clause. See [fidelity-gaps.md](./fidelity-gaps.md). |
-| `skills.proactive_suggest_enabled` | gate `1598976391` (`proactiveSkillSuggestEnabled`) override | Only consulted when `suggest_enabled` (effective) is true. `true` swaps `suggest_skills` to the proactive description, adds an optional `trigger` enum param (`user_asked` \| `proactive`), and chains the empty-catalog `note` into `search_plugins`. Omit to use the synced baseline gate — **on** from the `1.24012.11` baseline, which is what production serves; the fallback for a baseline predating the gate is `false`. |
+| `skills.proactive_suggest_enabled` | gate `1598976391` (`proactiveSkillSuggestEnabled`) override | Only consulted when `suggest_enabled` (effective) is true. `true` swaps `suggest_skills` to the proactive description, adds an optional `trigger` enum param (`user_asked` \| `proactive`), and chains the empty-catalog `note` into `search_plugins`. Omit to follow the baseline: from the `1.46388.3` baseline Desktop does not read the gate and proactive mode is **always on**, so the gate row is ignored; for an older baseline the synced gate decides (**on** from `1.24012.11`; `false` for a baseline predating the gate). On a baseline from `1.46388.3`, `false` builds a non-proactive `suggest_skills` that production does not ship there; use it only to exercise the older surface. |
 | `mcp.config` / `mcp.enabled[]` | `--mcp-config` / `enabledMcpjsonServers` | the supported way to attach an MCP server to a session under test. |
 
 > Inside a git repo, `folders[]` and `skills.local[]` stage only **git-tracked** files into the mount (matching

package/examples/replays/README.md

@@ -16,7 +16,7 @@ DOES exercise a real gate exchange, see `example-multiselect-gate.cassette.json`
 
 Run it with:
 
-> Assumes the `cowork-harness` CLI is available — from a source checkout run `npm ci && npm run build && npm link` first, or `npm i -g "cowork-harness@^3.8.0"`. (`replay` itself needs nothing else — no token, no Docker.)
+> Assumes the `cowork-harness` CLI is available — from a source checkout run `npm ci && npm run build && npm link` first, or `npm i -g "cowork-harness@^3.8.1"`. (`replay` itself needs nothing else — no token, no Docker.)
 
 ```sh
 cowork-harness replay examples/replays/example-pdf-skill.cassette.json

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cowork-harness",
-  "version": "3.8.0",
+  "version": "3.8.1",
   "description": "Scriptable, CI-friendly harness for Claude Cowork's runtime contract for testing skills across scenarios \u2014 same agent, mounts, egress allowlist, permission protocol, and sandbox limitations.",
   "license": "MIT",
   "type": "module",

package/schema/session.schema.json

@@ -200,7 +200,7 @@
           "type": "boolean"
         },
         "proactive_suggest_enabled": {
-          "description": "override for gate 1598976391 (proactiveSkillSuggestEnabled): when true (and suggest_enabled is not false), suggest_skills swaps to the proactive description, gains an optional `trigger` enum param, and chains its empty-catalog note into search_plugins. Omit to use the synced baseline gate — on from the 1.24012.11 baseline, matching what production serves; the fallback for a baseline that predates the gate is false.",
+          "description": "override for gate 1598976391 (proactiveSkillSuggestEnabled): when true (and suggest_enabled is not false), suggest_skills swaps to the proactive description, gains an optional `trigger` enum param, and chains its empty-catalog note into search_plugins. Omit to follow the baseline: from the 1.46388.3 baseline Desktop does not read the gate and proactive mode is always on; for an older baseline the synced gate decides (on from 1.24012.11; false for a baseline that predates the gate). On a 1.46388.3+ baseline, false builds a non-proactive surface production does not ship there.",
           "type": "boolean"
         }
       },