Bridge Claude plugin credentials to First Draft operations

[raghubetina]

Problem

Claude Code stores the First Draft api_token from /plugin as sensitive userConfig, but the create-full-stack-app Skill invokes firstdraft through the ordinary Bash tool. Claude only exposes ${user_config.*} to supported plugin components such as MCP, LSP, and hooks; a plugin bin/ executable is merely added to Bash PATH and does not receive the sensitive value.

The 0.1.0 adapter tests manually injected lowercase CLAUDE_PLUGIN_OPTION_api_token and CLAUDE_PLUGIN_OPTION_api_url, so they did not exercise the real Claude boundary. Claude 2.1.226 normalizes hook option names to uppercase. A real template-to-Codespace smoke therefore saved the token successfully but the CLI still returned authentication_required.

Current pragmatic path

Drawing Board will use a local gitignored .env and one repo-local CLI wrapper for both Claude and Codex. This is appropriate for the current development smoke, but the token is readable by the agent and ordinary repository tools.

Future improvement

Provide authenticated First Draft operations through a narrow plugin MCP server whose environment maps ${user_config.api_url} and ${user_config.api_token}. Keep secrets out of Skill content and general Bash. Remove the .env requirement only after a real-Claude integration test proves an authenticated request against a fake local endpoint.

Acceptance

• Install the packed plugin into an isolated real Claude Code profile.
• Configure a canary sensitive token through Claude, not by injecting adapter variables.
• Invoke the actual authenticated plugin component.
• Prove the fake endpoint received the expected authorization without printing the token.
• Prove general Bash and Skill content do not receive the sensitive value.
• Repeat the fresh template -> Codespace -> Claude -> ordinary app request journey before promotion.

Official boundary: https://code.claude.com/docs/en/plugins-reference#user-configuration

[raghubetina]

Review of an open issue. The problem statement is verified accurate by later work: Claude Code exposes
${user_config.*} only to supported plugin components (MCP servers, hooks, LSP), while a plugin bin/
executable is just a PATH entry for the Bash tool, so the stored api_token never reaches firstdraft
invocations. #28 subsequently removed the ineffective userConfig bridge rather than leaving code that
implied a capability that does not exist, which was the right interim move; this issue correctly stays open
for a real bridge. Currency note: any eventual design (MCP-wrapped invocation, a hook-injected environment, or
an explicit firstdraft login flow writing local credential state) should be weighed against the pre-alpha
posture in the firstdraft repo; a boring explicit-login flow may beat a clever bridge while the surface area
is this small.

[raghubetina]

This open issue documents a capability boundary that anyone building Claude Code plugins will hit, so it is
worth learning from other people's afternoon of confusion.

The mental model that fails: "the plugin stores the user's API token as userConfig, my plugin ships a CLI
on the Bash PATH, therefore my CLI can read the token." The reality: plugin configuration interpolation
(${user_config.*}) is delivered only to components the plugin system manages directly, such as MCP servers
and hooks. A binary that the Bash tool happens to find on PATH is outside that trust boundary; it runs as an
ordinary subprocess with no plugin-provided environment. The distinction is deliberate. Sensitive
configuration flowing automatically into every subprocess an agent shells out to would make each Bash
invocation a potential exfiltration path.

Two general lessons. First, secrets delivery is a designed channel, never an ambient inheritance; when a
platform does not hand your subprocess a credential, that is usually the security model working. Options that
respect it include wrapping the operation in a component the platform does trust (an MCP server that holds
the token) or an explicit login flow that stores the credential in the CLI's own config with user consent.
Second, note what the team did while the right design stayed open: they deleted the bridge that did not work
(#28) instead of shipping code whose presence implied the capability existed. An honest gap plus an open
issue beats a comforting no-op.