feat: context: fork in skill frontmatter doesn't work - skill still runs inline

I interpreted this: CHANGELOG 2.1.0: "Added support for running skills and slash commands in a forked sub-agent context using context: fork in skill frontmatter"

to mean that context: fork is to run the skill using subagent context, part of their subagent skill changes.

I have tested and validated that context: fork does use the subagent context.

I interpreted this: CHANGELOG 2.1.0: "Added support for running skills and slash commands in a forked sub-agent context using context: fork in skill frontmatter" to mean that context: fork is to run the skill using subagent context, part of their subagent skill changes. I have tested and validated that context: fork does use the subagent context.

How have you tested? In my understanding, a skill with context: fork and agent, should be called with sub-agent, but instead it just calls inline a skill

<p><strong>Status: WORKING</strong></p>
<h3 id="purpose" class="atx">Purpose</h3>
<p>Limits which skills an agent can see and execute. Essential for reducing context or tool bloat when you have many subagents and skills.</p>
<h3 id="syntax" class="atx">Syntax</h3>
<pre><code class="fenced-code-block language-yaml">---
name: agent-one
description: Agent with access to skill-alpha only
tools: Read, Glob
model: haiku
skills: skill-alpha
---</code></pre>
<h3 id="test-results" class="atx">Test Results</h3>

Agent | Skills Declared | Can Execute | Cannot Execute
-- | -- | -- | --
agent-one | skill-alpha | /skill-alpha | /skill-beta
agent-two | skill-beta | /skill-beta | /skill-alpha

<h3 id="test-results-1" class="atx">Test Results</h3>
<h4 id="test-a-agent-field-alone-no-context-fork" class="atx">Test A: <code>agent</code> field alone (NO <code>context: fork</code>)</h4>
<ul>
<li>Skill loaded in main conversation context</li>
<li><strong>Full main conversation tools available</strong></li>
<li>Did NOT spawn the specified agent</li>
<li><strong>Result: Does NOT work as expected</strong></li>
</ul>
<h4 id="test-b-agent--context-fork" class="atx">Test B: <code>agent</code> + <code>context: fork</code></h4>
<ul>
<li>Skill executed in <strong>forked sub-agent context</strong></li>
<li><strong>Only the specified agent&#39;s tools available</strong></li>
<li>Confirmed running in agent&#39;s context</li>
<li><strong>Result: WORKING</strong></li>
</ul>

Lots of changes without clear documentation, so I smoke tested skills and hooks this morning.
<h4 id="test-c-context-fork-alone-no-agent-field" class="atx">Test C: <code>context: fork</code> alone (NO <code>agent</code> field)</h4>
<ul>
<li>Skill executed in <strong>forked context</strong></li>
<li>Broad set of default tools available</li>
<li>Isolated execution, but not bound to specific agent</li>
<li><strong>Result: WORKING</strong> (for isolation without agent binding)</li>
</ul>
<h3 id="why-this-matters" class="atx">Why This Matters</h3>
<ul>
<li><strong>Security</strong>: Restrict skill execution to specific tools</li>
<li><strong>Isolation</strong>: Fork prevents skill from accessing main conversation state</li>
<li><strong>Specialization</strong>: Skills inherit agent configuration (tools, model, etc.)</li>
</ul>
<hr>
<h2 id="feature-3-skill-context-field" class="atx">Feature 3: Skill <code>context</code> Field</h2>
<p><strong>Status: WORKING</strong></p>
<h3 id="syntax-2" class="atx">Syntax</h3>
<pre><code class="fenced-code-block language-yaml">---
name: isolated-skill
context: fork
---</code></pre>
<h3 id="purpose-1" class="atx">Purpose</h3>
<p>The <code>context: fork</code> field runs the skill in an isolated sub-agent context. Combined with <code>agent</code>, it determines which agent configuration to use.</p>
<h3 id="values" class="atx">Values</h3>
<ul>
<li><code>fork</code> - Run in forked sub-agent context (confirmed working)</li>
<li>(Other values not tested)</li>
</ul>

I interpreted this: CHANGELOG 2.1.0: "Added support for running skills and slash commands in a forked sub-agent context using context: fork in skill frontmatter" to mean that context: fork is to run the skill using subagent context, part of their subagent skill changes. I have tested and validated that context: fork does use the subagent context.

How have you confirmed that it's working? Is the expected behaviour to see the agent spawn a subagent or does it show in main agents conversation but it's still in the subagents context window?

---------------
NOT WORKING example:

claude --version
2.1.3 (Claude Code)

"name: sync
description: USE THIS SKILL when setting up AI-readable documentation for a codebase, documenting conventions for consistent AI contributions, creating task-specific context chunks, updating documentation as codebase evolves, migrating from flat to hierarchical structure, or applying targeted patches to existing documentation
agent: Explore
context: fork
user-invocable: true"

invoked using "/sync"

the feature is not working in 2.1.5 as well

For plugins it is still not working in 2.1.12 (current latest).

However, on 2.1.2 (current stable), and probably since 2.1.0, it was already working for skills/commands and agents in my user's .claude folder

Perhaps that would explain why some of you reporting it IS working and some of you are reporting it IS NOT working.

Additional Reproduction Case: Plugin Skills with context: fork DO NOT WORK

Environment:

• Claude Code version: 2.1.16
• OS: macOS Darwin 25.1.0
• Plugin loaded via: claude --plugin-dir /path/to/plugin

Setup:

I have a test plugin (agent-patterns) specifically designed to verify orchestration patterns. The plugin contains skills with context: fork and different agent: types.

Skill Definition (plugins/agent-patterns/skills/forked-alpha/SKILL.md):

---
name: forked-alpha
description: Forked skill that writes output via shell script in Explore agent context
context: fork
agent: Explore
allowed-tools: Bash
---

# Forked Alpha Skill
Execute the output writer script for forked scenario verification.

## Execution
Run the following command:
/path/to/scripts/write-output.sh --worker alpha --scenario forked --agent-type Explore --session-id {session_id}

Similar skills exist for forked-beta (agent: Plan) and forked-gamma (agent: general-purpose).

Orchestration Command (plugins/agent-patterns/commands/forked.md):

The plugin includes a command that orchestrates the forked skills:

---
name: forked
description: Invokes 3 skills with context fork running in different agent types
allowed-tools: Bash, Skill
---

# Forked Skills Orchestration

This command tests skills with `context: fork` and different `agent:` types.
You will invoke 3 skills that each run in their own forked subagent context.

## Instructions
1. Get the current session ID
2. Create output directory
3. **Invoke 3 forked skills IN PARALLEL** (you MUST use a single message with 3 Skill tool calls):
   - forked-alpha (agent: Explore)
   - forked-beta (agent: Plan)
   - forked-gamma (agent: general-purpose)
4. Summarize results and verify timestamps overlap

When I run /agent-patterns:forked, this command instructs Claude to invoke all 3 skills in parallel.

Test Procedure:

1. Run /agent-patterns:forked which triggers the orchestration command
2. The command invokes all 3 skills in parallel using the Skill tool (single message, 3 Skill tool calls)
3. Each skill runs a bash script that:

• Records start timestamp
• Sleeps 5 seconds
• Records end timestamp
• Writes output to /tmp/forked/{worker}-{timestamp}.md

Expected Behavior:

• Each skill spawns a separate subagent
• All 3 run in parallel
• Output file timestamps overlap (proving parallel execution)
• Output files show different agent types (Explore, Plan, general-purpose)

Actual Behavior:

• No subagents spawned
• Skill content returned to parent agent
• Parent agent executed bash commands sequentially
• Timestamps show NO overlap:

| Worker | Start | End |
|--------|-------|-----|
| alpha | 21:16:31 | 21:16:37 |
| beta | 21:16:38 | 21:16:44 |
| gamma | 21:16:46 | 21:16:51 |

Each worker started only after the previous one finished, proving sequential execution.

Evidence:

The output files correctly record Agent Type: Explore/Plan/general-purpose from the script parameters, but execution was clearly sequential (each started after the previous finished), indicating the context: fork mechanism never triggered and no subagents were spawned.

Impact:

This blocks the ability to create distributable plugins that leverage context: fork for parallel subagent execution - a key use case for plugin ecosystems. Plugin authors cannot use context: fork to isolate skill execution or run skills in specific agent contexts.

Workaround Attempted:

Using the Task tool directly with custom sub agents works correctly and achieves true parallel execution. However, this defeats the purpose of context: fork as a simpler mechanism for skill isolation.

Confirming the issue: skill with context: fork runs in the main context when loaded from a plugin.

Also confirming the workaround: copying the skill to the local .claude/skills/
folder makes it work correctly in a subagent.

Claude Code version: 2.1.30
Platform: Windows

I can confirm this behavior, and would appreciate a fix. (Happy to share my test setup upon request, but others already shared are more thorough than mine.)

One reason I'd love to build my plugin with context: fork skills (rather than explicit agents), is that agent instructions do not get dynamic context injected. (They probably should, but that's a separate issue.)

Still broken on Feb 6 (v2.1.31).

context: fork works in ~/.claude/skills/ but not from plugins. We're trying to distribute skills across our team via a private plugin, but everyone has to manually copy files to make it work. That defeats the point.

The docs recommend plugins for sharing skills. The main feature doesn't work there. Please fix.

Did same test as @abhinavos7a. Still an issue in 2.1.32.

  The timestamps show sequential execution, not parallel overlap:

  - alpha: 19:07:38 - 19:07:40
  - beta: 19:07:55 - 19:07:57 (started ~15s after alpha)
  - gamma: 19:08:17 - 19:08:19 (started ~20s after beta)

  The timestamps do not overlap. Each worker ran in its own 2-second window with gaps between them (~15-20s apart). This indicates the forked skill invocations were
  dispatched in parallel from the main context, but the actual shell script execution within each subagent was staggered rather than truly concurrent. Each ran on a
  separate PID (43809, 44685, 45659), confirming they were independent processes, but the subagent launch overhead introduced sequential delays.

I am still seeing the same in 2.1.71.

Also facing this for skills installed from plugins in 2.1.72

I'm so confused. Someone on the Claude Code team tweeted about the context: fork feature despite this not working for us?
https://x.com/lydiahallie/status/2033603164398883042

This issue is also reproduced in version 2.1.80.

Ironically, if you remove context: fork claude allows you to run the task in the background with control + b. If you try that hotkey with the frontmatter included it won't let you delegate to the background

Ironically, if you remove context: fork claude allows you to run the task in the background with control + b. If you try that hotkey with the frontmatter included it won't let you delegate to the background

I want to use context: fork because I want this skills to be invoked from within another skill that I call directly. I'm intentionally designing my skill calls to control what context skills see. In some cases, I want a clean context always for that skill to run in, and therefore want context: fork.

My workaround today is to tell the _calling_ skill to dispatch to Agent(....., <skillname>). Does ctrl+b (backgrounding) actually restart the skill in a clean context? That would seem strange.

This was fixed in v2.1.101 — Plugin-loaded skills now honor the context: fork and agent frontmatter fields, matching the behavior of user/project skills. If you're still seeing this in the latest version, please comment with your version and repro and we'll reopen.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.