Forked-skill Agent dispatch fails in VSCode extension 2.1.140 — sub-agent loses skill context and tool whitelist

Resolved 💬 1 comment Opened May 12, 2026 by ozandrewkerr Closed Jun 12, 2026

Summary

In Claude Code VSCode extension v2.1.140 (and likely v2.1.139), forked-skill dispatch via Agent(prompt: "Invoke the X skill...", run_in_background: true) no longer works. The launched sub-agent does not appear to receive the skill's SKILL.md as its instruction set, and its available tool surface does not match the skill's allowed-tools frontmatter. The result is that the sub-agent cannot execute the skill and bails out without producing artifacts.

Worked on prior versions; broke after auto-update.

Environment

  • macOS 14 (Darwin 23.0.0)
  • VSCode Claude Code extension: anthropic.claude-code-2.1.140-darwin-arm64
  • Also present on disk: anthropic.claude-code-2.1.139-darwin-arm64 (installed May 12, ~24h earlier — may also be affected; not yet isolated)
  • CLI binary at ~/.local/bin/claude: 2.1.119 (unused in this session)
  • Model: claude-opus-4-7[1m]

Reproducer

Any project with a skill containing context: fork in its SKILL.md frontmatter. Example skill frontmatter:

---
name: memo
context: fork
allowed-tools: Read, Glob, Grep, Write, WebFetch, WebSearch, Bash
---

Orchestrator dispatch (per documented pattern):

Agent(prompt: "Invoke the memo skill for [TICKER]...", run_in_background: true)

Observed behavior

  1. The Agent launch succeeds (orchestrator gets agent ID and output file).
  2. The sub-agent runs briefly, makes zero hook-logged tool calls, and exits.
  3. The sub-agent's returned message reports that it could not find an Agent or Skill tool to "invoke" the named skill, and that its available tool surface is restricted to TaskStop, Monitor, TodoWrite, WebFetch, WebSearch, finance MCPs, and worktree/skill-management tools — notably missing the Read, Bash, Write, Glob, Grep tools listed in the skill's allowed-tools whitelist.
  4. The sub-agent therefore cannot execute the skill template even if it interpreted the task correctly.

Expected behavior

Per documented behavior and prior versions: Agent with a prompt referencing a context: fork skill should run the sub-agent as that skill, with SKILL.md loaded into its system prompt and the skill's allowed-tools whitelist forming the upfront tool set.

Likely root cause (speculation)

This session uses a deferred-tools mechanism where tools are not present upfront and must be loaded via ToolSearch before they can be called. For the parent/orchestrator this works fine. For forked sub-agents, the deferred-tools catalog appears to be more restrictive than the parent's, and does not include the skill's declared allowed-tools. Possibly the intersection between the deferred-tools catalog and the skill whitelist is computed incorrectly, or the SKILL.md auto-injection step is missing in the new dispatch path.

Impact

Any project that uses forked skills as a parallelization or context-isolation primitive is blocked. In my case this affects four production skills (memo, review, qualify, hedge) that drive a multi-agent investment research pipeline. The documented "Orchestrator → fan-out via Agent → fork-context skills" pattern is unusable.

Workaround

Drop to the Claude Code CLI binary (older version, pre-deferred-tools) for forked-skill dispatch, and use the VSCode extension only for foreground/interactive work.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗