Skip to content

fix: stop passing a skills allowlist to Claude Code sessions#67

Merged
SawyerHood merged 1 commit into
mainfrom
sawyer/fix-claude-skills-allowlist
Jun 5, 2026
Merged

fix: stop passing a skills allowlist to Claude Code sessions#67
SawyerHood merged 1 commit into
mainfrom
sawyer/fix-claude-skills-allowlist

Conversation

@SawyerHood
Copy link
Copy Markdown
Collaborator

Problem

Using any user-installed skill (e.g. from ~/.claude or a Claude Code plugin) inside a bb-managed Claude Code session fails with:

Skill frontend-design is not in this session's skills allowlist

The claude-code adapter forwarded bb's injected skill names as the Agent SDK skills option. Per the SDK docs, skills: string[] enables only the listed skills — a session-wide allowlist that hides and rejects everything else. The plumbing shipped in 8d02034 but only activated when injected skills existed; once 5f87c16 bundled building-bb-apps as a builtin injected skill, every session ran with the allowlist set to just the injected skills, breaking user-installed skills everywhere.

The allowlist was never needed: injected skills load as a local plugin via the SDK plugins option, and plugin skills are enabled by CLI defaults. (settingSources already includes user, so ~/.claude skills were discovered all along — just rejected at invocation.)

Fix

Remove the allowlist end-to-end rather than leave dead plumbing (accepted-but-ignored fields are forbidden):

  • adapter: buildClaudeSkillConfigParams emits plugins only, with a comment pinning why skills must never be set here
  • bridge: drop skills from the thread/start + thread/resume schemas, BuildSessionOptionsArgs, SdkSessionOptions, and the query() call
  • runtime: drop skillNames from AgentRuntimeClaudeCodeSkillRoot and its normalization
  • host-daemon: staging no longer attaches skill names to the claude-code skill root (plugin.json still lists them, which is what enables them)

Codex and pi adapters are additive ("extra roots") and were never affected.

Tests

  • Regression pins at three layers (adapter command params, buildSessionOptions, SdkSession.start query options) assert no skills allowlist reaches the SDK
  • Existing integration test still verifies injected plugin skills are usable per provider
  • turbo run typecheck + test for @bb/agent-runtime (567 tests) and @bb/host-daemon (386 tests) pass

🤖 Generated with Claude Code

The claude-code adapter forwarded injected skill names as the Agent SDK
`skills` option. That option is a session-wide allowlist — "enable only
the listed skills" — so any session with injected skills hid and
rejected every other skill (user ~/.claude skills, plugin skills,
built-ins) with "not in this session's skills allowlist". Since
5f87c16 bundled building-bb-apps as a builtin injected skill, every
session had the allowlist active, breaking user-installed skills
everywhere.

The allowlist was never needed: injected skills load as a local plugin
via the SDK `plugins` option, and plugin skills are enabled by CLI
defaults.

Remove the allowlist end-to-end rather than leave dead plumbing:
- adapter: buildClaudeSkillConfigParams emits plugins only, with a
  comment pinning why `skills` must never be set here
- bridge: drop `skills` from thread/start + thread/resume schemas,
  BuildSessionOptionsArgs, SdkSessionOptions, and the query() call
- runtime: drop the skillNames field from AgentRuntimeClaudeCodeSkillRoot
  and its normalization
- host-daemon: staging no longer attaches skill names to the claude-code
  skill root (plugin.json still lists them, which is what enables them)
- tests: regression pins at the adapter, session-options, and SdkSession
  layers assert no `skills` allowlist reaches the SDK

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@SawyerHood SawyerHood merged commit 209513a into main Jun 5, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant