A customization enabled in a Claude account can become part of a developer's terminal environment. Claude Code's September 17, 2026 release, v2.1.275, documents account skill and plugin sync into terminal sessions and settings to opt out. For security teams, the change adds an account-controlled distribution path to the local inventory they already review.
The immediate decision is whether that path may deliver instructions, executable plugin components, or both. A restriction on how a standalone skill's text is processed says little about the authority of a complete plugin. Review the two separately before expanding a rollout.
This guide turns the documented behavior into an administrator review procedure. We have not tested the configuration in a tenant. Use it alongside the broader Claude Code enterprise deployment baseline.
Establish which terminals are in scope#
Check the installed version. Current documentation places terminal sync support at v2.1.273 or later, before the September 17 v2.1.275 announcement.
The skills documentation describes account sign-in through /login; API-key and token-only sessions do not use this sync path. Skills download in the background and refresh roughly every ten minutes. Cached skills for the same account can remain available offline.
For a fleet review, record the client version, authentication route, account organization, and effective managed policy. An API-backed CI job and an account-signed-in laptop are different rollout cases. A disconnected laptop is also a poor place to infer the current account configuration from what remains on disk.
See how your AI systems hold up under real attacks
General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.
Compare the components before approving the source#
Anthropic documents different behavior for standalone synced skills and synced plugins.
| Account content | Documented terminal behavior | Security review task |
|---|---|---|
| Standalone synced skill | Skill frontmatter remains effective; body shell preprocessing and automatic file attachment are restricted. | Read its instructions and requested tools. Suppressed preprocessing does not establish harmless behavior. |
| Synced plugin | Loads as <name>@synced with marketplace-plugin trust. Skills, agents, hooks, MCP servers, and LSP servers can load. | Inspect the bundle's components and the authority each needs. |
| Another enabled plugin with the same name | A copy from another source can take precedence over the synced copy. | Identify the copy actually loaded before interpreting a disable or removal result. |
Consider a hypothetical release-review customization. A team might approve instructions that summarize a diff. A plugin with that name could also contain a hook or server configuration. The approval record should describe the reviewed contents and source, rather than treating the familiar name as sufficient evidence.
In /plugin, the Installed tab identifies synced entries. Its detail view lists the plugin's components; the plugin management documentation also describes the CLI inventory and detail commands. Capture those details before deciding whether a bundle fits the endpoint's policy. For a server, ask which credentials and destinations it needs. For a hook, review the action and triggering event.
Installer protections answer a separate question. The same September 17 release hardened npm plugin fetching with --ignore-scripts and integrity verification. Those changes do not constitute an approval of the components loaded later. If the concern is a suspicious installation, follow the Plugin4Shell response guide as an incident workflow.
Set a narrow account-sync policy#
An organization that has not approved this distribution path can disable both sync settings in managed policy. Merge the following illustrative fragment into the existing policy; replacing the whole file would discard unrelated controls.
Code source: illustrative, using the opt-outs documented in the v2.1.275 release.
{
"syncClaudeAiSkills": false,
"syncClaudeAiPlugins": false
}
The two settings allow separate decisions. If instructions are approved but plugin bundles still need review, set the plugin control to false and evaluate the skill policy independently. Document who approves exceptions and which repositories may use them.
Use the organization's existing managed-settings delivery method. Anthropic's policy verification procedure uses /status to identify the selected managed source and claude doctor to explain discarded settings. A file reaching the laptop is only the first checkpoint. Confirm the expected source is selected and investigate diagnostics before calling the rollout effective.
Verify removal after the relevant lifecycle step#
For standalone skills, syncClaudeAiSkills: false stops downloads and moves synced files to ~/.claude/skills/.trash/ on the next start. Deleting the synced folder manually is temporary while the skill stays enabled in the account. A local short-name collision can also leave the synced skill available under its qualified name. These are documented in the skill lifecycle rules.
Plugins check the account at startup. Changes downloaded into an interactive session require /reload-plugins or another start to activate. Setting syncClaudeAiPlugins: false moves synced plugins to ~/.claude/plugins/.trash/ at the next start. An organization-required plugin cannot be individually disabled by the user. See the synced-plugin lifecycle.
Use a small, approved pilot to collect the following evidence. These are proposed acceptance checks, not reported test results:
- Before policy delivery: save the version, authentication route, selected settings source, and inventory with source labels. Assign an owner to each unexpected component.
- After delivery and restart: repeat the inventory and diagnostics. Confirm that the account-sourced entries covered by the policy no longer load. Investigate remaining copies by source.
- For an individual removal: record whether the change came from the account, organization, or local plugin control. Apply the documented refresh or restart step before comparing results.
- Before closing the change: check the active session as well as stored files. Keep evidence of the policy received, the lifecycle step completed, and the resulting inventory together.
Move-to-trash behavior establishes neither secure erasure nor credential revocation. If a component had access to a connected service, its owner must separately decide whether credentials or grants need revocation. The broader coding-agent security guide covers those authority boundaries.
Frequently asked questions
- Should a plugin's name be enough to approve it?
Record its source and components as well. A review should identify the particular copy allowed on the endpoint, the authority it needs, and the team responsible for removing it.
- Is disabling account sync a complete plugin policy?
Treat it as one distribution control. Review other plugin sources, tool permissions, server credentials, and endpoint policy separately before approving the deployment.
