### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? When invoking a skill from another skill the workflow execution from the invoking (main) skill is discontinued. I have experimented with this behavior an

[BUG] Nested skills dont return to invoking skill context on finishing but to main context

Status Open

Reported on v2.1.3

Maintainer reply None cached

Workaround ✓ Mentioned in thread ↓

Activity 5 comments · opened Jan 10, 2026

Preflight Checklist

[x] I have searched existing issues and this hasn't been reported yet
[x] This is a single bug report (please file separate reports for different bugs)
[x] I am using the latest version of Claude Code

What's Wrong?

When invoking a skill from another skill the workflow execution from the invoking (main) skill is discontinued.

I have experimented with this behavior and used the new context: fork and agent: with the nested skill to define a different model (Haiku) for the invoked skill. The main skill was invoked with a command and a different model (Sonnet). After the skill finished, the session returned to the main context (Opus). This also happens without the context forking.

A skill with a workflow that delegates a task to another skill (forked or not) cannot continue the workflow. Manually asking to continue it shows that Opus is used (Strg + O/E).

The invoked skill did not contain directives to finish or create a report or something similar.

What Should Happen?

The execution should return to the skill and not the main session. If the behavior is intended, the limitations of context nesting should be documented.

Error Messages/Logs

Steps to Reproduce

Create a skill that invokes another skill explicitly (Skill(...)).
Create a command with a different model than the main session that invokes the main skill explicitly.
Run the command and observe the used model in the session transcript

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.3

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

_No response_

View original on GitHub ↗

5 Comments

corticalstack · 7 months ago

Indeed, this is breaking attempts to create a custom ralph wiggum implementation, where after execution of a skill, control is returning to human interaction and so breaks my ralph's autonomous loop.

him0 · 7 months ago

I experienced the same issue.

My /git-pull-request skill calls /git-commit --push as a pre-processing step before creating a PR. After /git-commit completed successfully (committed and pushed), the workflow stopped and returned to the main session instead of continuing with the PR creation.

Claude even said "Commit and push completed. I'll create the PR." but didn't actually proceed to call the next tool. I had to manually prompt it to continue.

This confirms the behavior described in this issue - nested skills don't return to the invoking skill context.

Claude Code Version: v2.1.9
Platform: macOS

virhdr · 7 months ago

I also experienced exactly the same issue (#21672 )

This is a bit unfortunate, because working with sub-skills is really powerful for bigger tasks.

Platform is Windows in my case. Also doesnt matter if its in VS Code plugin or the CLI.

bgeesaman · 6 months ago

Same issue here. It happens when skills call other skills. I can't get a prompt calling a list of N skills to complete. After skill 1 is run, it ends the turn.

Two skills in ~/.claude/skills/skill1 and 2:

Run the following skills in order (start the next one after the prior one completes):
    1. /skill1
    2. /skill2

Behavior: stops after skill1 and never invokes skill2

Version: 2.1.37
OS: MacOS

timherby · 3 months ago

Could a maintainer share whether a fix is in progress and approximate priority?
The issue's been open since January with has repro and area:core; a status signal would help us decide how much more workaround infrastructure to invest in.

We're hitting this in production with Claude Code (Agent SDK via claude-code-action in CI). We've tried several per-skill workarounds across ~10 orchestrator skills — instructing the model to load the sub-skill's SKILL.md directly via the Read tool instead of invoking it — and still see the bug fire whenever the model doesn't comply with the prose. Example workaround pattern:

# Anti-pattern that exhibits the bug — orchestrator's workflow doesn't resume:
Skill(skill="write-pr")

# Per-skill prose workaround we documented:
# "Do NOT use Skill() — Read the sub-skill's SKILL.md and execute its
#  workflow inline so execution stays inside the same tool-use flow."
Read(".claude/skills/write-pr/SKILL.md")

Two production runs failed four days after we deployed that workaround: the model invoked Skill(...) anyway, the bug fired (clean stop_reason: end_turn, but the orchestrator's remaining workflow steps never executed).