What you will be able to do
- Explain how plugins are installed and loaded in the terminal, claude -p, the Agent SDK and claude.ai
- Choose a plugin scope and predict which settings file it writes and what collaborators still have to do
- Account for the per-turn context cost of an enabled plugin and choose between disabling and uninstalling it
- Predict what a resumed session restores and what it doesn't, and name sessions so they can be resumed reliably
1.One plugin, several surfaces
A plugin bundles several kinds of capability. It can include skills (SKILL.md instructions that Claude loads when relevant), subagent definitions Claude can hand work to, hooks that run at points in Claude Code's lifecycle, and MCP servers. How a plugin reaches Claude depends on the surface you work in, and the differences are easy to overlook when you move a workflow from one surface to another.
| Surface | How plugins arrive |
|---|---|
| Terminal, Desktop app, VS Code, Cloud session | Interactive install through /plugin |
| claude -p and other non-interactive runs | /plugin is unavailable, but plugins you already installed still load. Manage them with claude plugin commands |
| Agent SDK | Loaded through the SDK's plugin option |
| claude.ai account or organization | Synced into Claude Code in the background and listed as <name>@synced |
Syncing goes one way only. Plugins you turn on in claude.ai appear in Claude Code, but plugins you install locally never go up to your claude.ai account. A script that installs from the official marketplace on a new machine must first run claude plugin marketplace add anthropics/claude-plugins-official, because that marketplace isn't registered until someone opens an interactive session. These sources cover plugin delivery across surfaces. They don't document how system prompts differ between the API, Desktop and claude.ai.
Sources1
2.Plugin scope, context cost and removal
| Scope | Enabled for | Entry written to |
|---|---|---|
| User | You, in every project on this machine | enabledPlugins in ~/.claude/settings.json |
| Project | Everyone who works in this repository | .claude/settings.json (committed) |
| Local | You, in this repository only | .claude/settings.local.json |
Project scope enables a plugin for your collaborators but doesn't install it on their machines. Each of them still runs claude plugin install <name>@<marketplace> --scope project once. An enabled plugin also costs context even when you never use it. The name and description of every skill, agent and command Claude can invoke on its own are sent on every turn. The full text loads only when the item is used. Plugins in the official marketplace show both token estimates, per turn and when invoked, before you install. And a plugin's actions run with your permissions.
Plugins load at startup or on /reload-plugins. If a reload would invalidate the prompt cache, Claude Code warns you and leaves the plugin pending. /reload-plugins --force activates it anyway, at the cost of one uncached request. To stop a plugin without removing it, disable it. On a project-scope plugin, pressing y writes false to your .claude/settings.local.json only, while u removes the plugin for everyone. Uninstalling a plugin leaves its auto-installed dependencies in place until you run claude plugin prune.
An agent has already analyzed a codebase's authentication module in an existing session and produced a JWT-based migration plan. The team now wants to explore an alternative OAuth2-based approach in a separate line of investigation without losing the ability to continue the original JWT-focused thread later. Which approach satisfies both goals?
Correct answer: A — Resume the original session with `fork_session=True` (or `forkSession: true`) and the OAuth2 prompt, which creates a new session with a copy of the original's history while leaving the original session's ID and history unchanged
- A. Correct. Forking with `resume` plus `fork_session: true` creates a new session that starts as a copy of the original's history and diverges from that point, while the original session's ID and history remain untouched, letting the team explore OAuth2 in the fork and still resume the original JWT thread separately.
- B. Incorrect. A plain `resume` call continues and appends to the original session's own history in place; it does not create a separate branch or preserve an untouched copy under a different ID the way fork does.
- C. Incorrect. Manually pasting analysis into a fresh prompt does not give the agent the same accumulated context (file reads, tool results) as a real session history, and it does not preserve a resumable original thread as cleanly as forking does.
- D. Incorrect. `continue` finds and continues the most recent session in the current directory; it does not automatically detect topic changes and branch into a new session, so it would not create the isolated exploration the team wants.
3.What a resumed session brings back
| Command | What it does |
|---|---|
| claude --continue | Reopens the most recent conversation in the current directory |
| claude --resume | Opens the session picker |
| claude --resume <name> | Resumes the named session directly |
| claude --from-pr <number> | Opens the session picker filtered to sessions linked to that pull request |
| /resume | Switches to a different conversation from inside an active session |
Neither of them runs again. A resumed session restores the full conversation history, including tool calls and their results, but background Bash and monitor tasks aren't restored. A tool that was cut off neither finishes nor reruns. Claude sees it marked as interrupted and is told to check whether it took effect before trying it again. Scheduled tasks that haven't expired and an active goal do carry over. The session keeps its model, unless a --model flag or an ANTHROPIC_MODEL-family variable chooses one at launch, or that model has been retired. The permission mode is restored when you resume from a terminal. It isn't restored when you use the session picker or /resume, and a claude -p resume starts in the mode a new claude -p run would use.
Sources3
4.Naming and compacting sessions
A session is only easy to get back to if you can find it again. Name it at startup with claude -n auth-refactor, or during the session with /rename. The default display name, such as my-app-3f, only identifies a session in listings and can't be used to resume it. If you don't name a session, a Haiku-class model generates a title from your first prompt. That title does work with --resume. A claude -p run started from a script never gets a generated title, so name any scripted sessions you'll want to resume.
Long histories cost tokens each time they are replayed. When you resume a session, you can choose Resume from summary. That runs /compact straight away and replaces the history with a summary, your most recent exchanges, and up to five recently read files. The alternative, Resume full session as-is, reprocesses and re-caches the entire history after your first message.
A developer defines a JSON Schema for an agent's `outputFormat` describing a deeply nested object with many required fields spanning several levels. In testing, most runs end with a `structured_output` field missing and the result message's subtype set to `error_max_structured_output_retries`, even though the underlying task usually succeeds. Which two changes are most likely to reduce these structured-output failures? (Select 2)(Select 2)
Correct answers: A, B — Simplify the schema by flattening unnecessary nesting and reducing the number of required fields, keeping only the fields the task can reliably produce; Mark fields optional when the underlying task might not always have that information available, instead of requiring every field unconditionally
- A. Correct. Anthropic's documented tips state that deeply nested schemas with many required fields are harder for the agent to satisfy, and keeping schemas focused reduces the chance of hitting the retry limit.
- B. Correct. The documented guidance is to match the schema to the task by making fields optional when the task might not always have that information, rather than requiring fields unconditionally and forcing failed validation when data is missing.
- C. Incorrect. The documented causes of structured-output failure are schema complexity, task ambiguity, and retry-limit exhaustion (or a model-fallback retraction), not insufficient `max_tokens`; raising it does not address why validation keeps failing.
- D. Incorrect. Changing the top-level type to `string` would abandon structured object output entirely rather than fixing validation of the intended object shape, defeating the purpose of using structured outputs.
- E. Incorrect. The `format` keyword is accepted only as an annotation and is not enforced by the SDK's validator, so adding it to every field would not tighten validation or reduce retries.
Sources3
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Committing a project-scope plugin entry to .claude/settings.json installs the plugin for every collaborator.Why is that wrong?
The committed entry only enables the plugin. Each collaborator still runs claude plugin install with --scope project once on their own machine.
Covered in Plugin scope, context cost and removal
2.An enabled plugin you never invoke costs nothing.Why is that wrong?
The name and description of each skill, agent and command Claude can invoke on its own are in context on every turn. They count toward your usage and take up room in the context window.
Covered in Plugin scope, context cost and removal
3.Resuming a session brings back everything that was running, including background shell tasks.Why is that wrong?
Scheduled tasks that haven't expired are restored. Background Bash and monitor tasks are not.
Covered in What a resumed session brings back
Practise it for real
Install a plugin at project scope, check its footprint, and turn it off without uninstalling it
1.In an interactive session, run /plugin install commit-commands@claude-plugins-official
Why: Naming the marketplace opens the details pane that shows the context cost estimates
You should see: A 'Will install' list and two Context cost estimates: every turn and when invoked
2.Choose 'Install for all collaborators on this repository'
Why: Project scope enables the plugin for the team through a committed file
You should see: An entry in .claude/settings.json, and a summary saying Active now, Reload needed or Load failed
3.In your shell, run claude plugin list
Why: Confirms the plugin is present and shows its scope without opening a session
You should see: The plugin listed with Version, Scope and Status lines
4.Run claude plugin disable for the plugin
Why: Disabling stops its per-turn context cost and keeps it installed
You should see: The plugin stays installed but no longer loads
Stuck? Get a nudge
If the install summary says Reload needed, run /reload-plugins. It warns you instead of reloading if the reload would invalidate the prompt cache.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://code.claude.com/docs/en/plugins/installOfficial docs
“Agent SDK: load plugins through the SDK’s plugin option.”
↩︎ One plugin, several surfaces“Plugins you already installed do load.”
↩︎ One plugin, several surfaces“plugins you install with /plugin or claude plugin install stay on this machine and aren’t added to your claude.ai account.”
↩︎ One plugin, several surfaces“If the reload would invalidate the prompt cache, it warns and leaves the plugin pending instead.”
↩︎ Plugin scope, context cost and removal“Uninstall: auto-installed dependencies stay until you run claude plugin prune in your shell”
↩︎ Plugin scope, context cost and removal“Committing that entry turns the plugin on for your collaborators but doesn’t download it to their machines”
↩︎ Exam trap 1 - 2.https://code.claude.com/docs/en/plugins/overviewOfficial docs
“The full text of a skill or agent loads only when it’s used.”
↩︎ Plugin scope, context cost and removal“Permissions: what the plugin runs, it runs as you.”
↩︎ Plugin scope, context cost and removal“Those tokens count toward your usage and leave less room in the context window even in sessions where nothing from the plugin runs.”
↩︎ Exam trap 2 - 3.https://code.claude.com/docs/en/sessionsOfficial docs
“Conversation history: the full history, including tool calls and results.”
↩︎ What a resumed session brings back“Claude sees the call marked as cut off before its result was recorded”
↩︎ What a resumed session brings back“/resume inside a session, with or without an argument: Claude Code doesn’t restore the stored permission mode.”
↩︎ What a resumed session brings back“The default isn’t a resume handle.”
↩︎ Naming and compacting sessions“A claude -p run you start directly from a shell or script doesn’t get one.”
↩︎ Naming and compacting sessions“Resume from summary: runs /compact immediately.”
↩︎ Naming and compacting sessions“Scheduled tasks: tasks that haven’t expired are restored. Background Bash and monitor tasks aren’t.”
↩︎ Exam trap 3