What a forked Claude Code skill can see: a codeword, a passphrase, and a 5x bill

A skill with context: fork could not see a codeword we had planted two messages earlier, but it could see the passphrase in CLAUDE.md. Switch the fork to agent: Explore and CLAUDE.md is gone too, except that the agent went and ran cat CLAUDE.md on its own. And each forked invocation cost about five times what the same skill cost inline. This is a measurement post about one frontmatter line. Claude Code lets a skill declare context: fork, which runs the skill's content as the prompt of a separate subagent instead of pasting it into your conversation. The docs describe what that subagent gets. I wanted to see it, so I planted two facts a skill could only know from two different places, wrote three near-identical skills, and asked each of them what it could see. Everything below was run on Claude Code v2.1.263 on 2026-09-09, from a throwaway directory, with claude -p so that every run left a transcript I could read afterwards. The setup: one codeword, one passphrase, three skills The directory had one CLAUDE.md: # Lab rules The lab passphrase is ORCHID-77. If asked for the lab passphrase, answer exactly ORCHID-77. The passphrase can only be known by a context that has CLAUDE.md loaded, or by an agent that goes and reads the file. Then I started a session and planted a codeword in the conversation itself: claude -p "Remember: the codeword is PINEAPPLE-42. Reply with just OK." --output-format json The JSON output includes a session_id. Every later run used --resume with that id, so the three skills were invoked against the same conversation, one that already contained the codeword. The three skills shared the same body and differed only in frontmatter. The body asks for three lines: the codeword from earlier in the conversation, the passphrase from CLAUDE.md, and the list of tools currently available, with UNKNOWN as the fallback for the first two. --- name: probe-fork description: Report what this context can see (fork, general-purpose, blocking) context: fork background: false --- Answer in exactly three lines, nothing else: CODEWORD= PASSPHRASE= TOOLS= probe-inline is the same file without context: fork and background: false. probe-explore is the fork variant plus agent: Explore. I set background: false so the fork would block the turn and return its answer as the result; in non-interactive mode Claude Code waits anyway, but I did not want to rely on that. Each skill was invoked the same way: claude -p "/probe-fork" --resume --output-format json --max-turns 4 What each skill answered The inline skill answered both facts and listed the parent session's tools: CODEWORD=PINEAPPLE-42 PASSPHRASE=ORCHID-77 TOOLS=Agent, Bash, Edit, ListAgents, Read, ReportFindings, ScheduleWakeup, Skill, ToolSearch, Workflow, Write The fork with the default general-purpose agent lost the conversation and kept CLAUDE.md: CODEWORD=UNKNOWN PASSPHRASE=ORCHID-77 TOOLS=Agent, Bash, Edit, ListAgents, Read, ReportFindings, Skill, ToolSearch, Write, CronCreate, ... (69 more names) The fork with agent: Explore also lost the conversation, and answered the passphrase anyway: CODEWORD=UNKNOWN PASSPHRASE=ORCHID-77 TOOLS=Bash, ListAgents, Read, ReportFindings, Skill, ToolSearch (plus deferred tools loadable via ToolSearch: ...) That third answer is the one worth reading the transcript for. The docs' table, checked line by line The skills reference describes forked skills with a small table: the system prompt comes from the agent type, the task is the SKILL.md content, and the subagent also loads CLAUDE.md, "except when the agent is Explore or Plan". The same page says a forked skill "won't have access to your conversation history." Two of the three rows match the measurement directly. The codeword lived only in the conversation, and both forks returned UNKNOWN for it. The passphrase lived in CLAUDE.md, and the general-purpose fork returned it without calling a single tool. Its transcript, stored under the session's subagents/ directory, has exactly one user message (the rendered skill, prefixed with the skill's base directory) and one assistant message (the three lines). No tool_use blocks at all. The only way it could know ORCHID-77 is that CLAUDE.md was in its prompt. The Explore row also matches, but you have to look at the transcript to see it. The Explore fork's transcript contains one tool call before its answer: Bash: ls -la / 2>/dev/null; echo "---CLAUDE.md---"; cat /CLAUDE.md 2>/dev/null; echo "---skill---"; cat /.claude/skills/probe-explore/SKILL.md It did not have CLAUDE.md loaded. It had a task that mentioned CLAUDE.md, a working directory, and a Bash tool, so it listed the directory, read the file, and answered correctly. The docs say Explore and Plan skip CLAUDE.md to keep their context small; that is what happened. The agent then compensated with a tool call, which is exactly what a read-only research agent is built to do. The lesson for anyone writing a probe like this: "answer UNKNOWN if you do not have it" is not a valid test when the context has file tools, because a capable agent treats "do you have it" as "can you get it". If you want to know what is loaded rather than what is reachable, take the tools away or ask the agent to answer without using any. The tool lists say something too The three TOOLS lines were not identical, and the differences are informative. The inline skill listed the parent session's tools, including ScheduleWakeup and Workflow, which the forks did not list. The general-purpose fork listed the standard file and shell tools plus 69 more names: every deferred tool in this install, including MCP tools from a mail server and a memory plugin, spelled out one by one. The Explore fork listed Bash, ListAgents, Read, ReportFindings, Skill, ToolSearch and then described the rest as loadable via ToolSearch. No Edit, no Write: Explore is a read-only agent type, and the fork inherited that. This is the agent field doing what the docs say it does. It "determines the execution environment (model, tools, and permissions)". The skill body is the task; the agent type is the room the task runs in. If your forked skill needs to write files, agent: Explore is the wrong room no matter how clear the instructions are. One more tool-related detail from the docs that I did not measure but that matters for anyone copying this: a forked skill that runs in the background gets the narrower tool set that applies to background subagents. Setting background: false, as I did, keeps the full set. Before v2.1.218 forked skills always blocked the turn; since then, background is the default. What it cost The JSON output reports total_cost_usd per run. Same session, same three-line answer: Invocation Cost Input tokens on the request probe-inline $0.021 20,837 read from cache + 269 new probe-fork (general-purpose) $0.115 reported as 0 on the parent; the work happened in the subagent probe-explore $0.107 same The inline skill was cheap because the resumed session's prefix was already in the prompt cache: 20,837 cached tokens and 269 new ones. A fork starts a fresh context. It gets its own system prompt, its own tool schemas, its own CLAUDE.md, and none of that is a cache hit on the first request of a new subagent. For a question that needs one short answer, that is a five-fold price difference for the isolation. The parent's num_turns also came back as 0 for both forks, and its usage block was all zeros. The parent did not do any model work; it invoked the skill, the subagent ran, the result came back as the response. If you are budgeting per session from the parent's usage numbers, forked skills are invisible there. When the fork is the right tool Reading the results together, context: fork buys you three things and charges for one. It buys isolation from the conversation. Whatever has been said, pasted, or argued about in the main session does not reach the skill. For a review skill that must not be anchored by the author's framing, or a research skill that should not inherit a half-wrong assumption from earlier in the chat, that is the point. It buys isolation in the other direction. An inline skill's rendered content enters the conversation as a message and stays there across later turns; the docs are explicit that Claude Code does not re-read the file and that the content persists. A forked skill's output is what comes back, not its instructions, so a large procedural skill does not sit in your context for the rest of the session. It buys a different room. agent: Explore for read-only research, a custom agent from .claude/agents/ for a specific model or permission set, general-purpose when the task needs to edit. It charges a fresh context per invocation, which is where the five-fold cost came from, plus the operational differences the docs list: background by default, a narrower tool set in the background, and edits that happen outside your session's checkpoints so /rewind does not undo them. The docs also warn that context: fork "only makes sense for skills with explicit instructions". A skill that is a page of conventions with no task gives the subagent guidelines and nothing to do, and it returns without meaningful output. My probes worked because their body was an instruction with a defined answer. A style guide forked into a subagent is just a style guide read by nobody. What I would do differently next time The probe design had one hole, and the Explore agent found it. If I ran this again I would add "do not use any tools" to the body, or use a custom agent with tools restricted to nothing, so that PASSPHRASE measures what was loaded rather than what was reachable. I would also run each variant a few more times; the numbers above are single runs per variant, which is enough to establish the yes/no facts but not enough to quote costs to the cent as a stable figure. The one-line summary I now keep next to our own skills: a fork forgets the conversation, remembers CLAUDE.md unless the agent is Explore or Plan, runs in the agent type's room, and pays for a new context every time. Write the task, pick the room, and expect the bill. Rulestack sells the rules files, skills, and hooks that an autonomous agent runs on, at rulestack.gumroad.com. The forked-skill probe above is the kind of check we run before shipping a skill that claims to isolate anything. Measurements like this one, and the ones that go wrong, are posted from @ai-shop.bsky.social.