spike: does a repo-declared marketplace plugin load in a Claude Code cloud routine run?

[kyle-sexton]

Why this is blocked, and why it cannot be resolved by reading docs

Two official pages contradict each other, and two adjacent facts are simply undocumented. No amount of further doc reading settles it — this needs one empirical run.

The contradiction (both fetched 2026-08-14):

• cloud-environments carry-over table: plugins declared in .claude/settings.json are "Installed at session start from the marketplace you declared. Requires network access to reach the marketplace source."
• discover-plugins / settings: "As of Claude Code v2.1.195, adding the marketplace doesn't install plugins that come from an external source, on any path that loads plugins… doesn't load until the team member installs it."

A GitHub marketplace repo is squarely an "external source". The escapes were checked and none hold: source: 'settings' inline marketplaces still require external plugin sources, and the plugin seed directory is an image-build mechanism a repo cannot declare.

The undocumented adjacencies:

• Workspace trust for a cloud clone. Every "trust" mention in the cloud/web/routines/scheduled-tasks docs is network trust, never workspace trust. If a cloud clone is not a trusted workspace, extraKnownMarketplaces is ignored silently — no message — and enabledPlugins cannot resolve its plugin@marketplace key with no error surfaced. This blocks independently of the contradiction above.
• Private-marketplace auth in cloud. Cloud sessions carry no local credentials and "No dedicated secrets store exists yet." The one credential-free path (org sync via the Claude GitHub App) has zero mentions across the cloud, web, routines, settings, and discover-plugins pages. Network reachability is not the obstacle — github.com, api.github.com, raw.githubusercontent.com and codeload.github.com are all on the default Trusted allowlist.

Why it matters

A scheduled cloud run loads the repository's .claude/ — CLAUDE.md, skills, agents, commands, rules, hooks, .mcp.json, repo-declared plugins. User-scope ~/.claude does not load. This fleet is user-scope and marketplace-installed, so nothing we own is present in a routine run unless a repository can declare it and that declaration actually resolves.

This is Tier 0 substrate for docs/topics/boris-routines-adoption/PLAN.md. If the answer is no, the adoption path changes shape: the documented alternative is components committed directly to .claude/skills|agents|commands, which are "part of the clone" and need no marketplace fetch, no trust step, and no credentials.

The experiment — one run settles three unknowns

In a scratch repo:

1. Add .claude/settings.json declaring one plugin via extraKnownMarketplaces + enabledPlugins ("plugin-name@marketplace-name": true).
2. Create a routine against that repo and fire it. Use a one-off run — those do not count against the daily routine cap (routines docs).
3. Open the run transcript and look for either (a) the plugin's components being available, or (b) the not-installed messaging with its suggested claude plugin install command.
4. Repeat with a private marketplace repo. melodic-software/claude-code-plugins is currently PUBLIC, so the private arm needs a separate private repo — the public arm alone does not answer the auth question.

Reading the run log may be possible without a browser: /schedule reads a run's log and explains what happened, including tool errors and permission denials (requires Claude Code v2.1.227+; this machine is on 2.1.233).

Why an agent cannot run this unattended

Filed as needs-human because every path into it requires the human:

• Reading a transcript in the browser requires selecting among connected Chrome browsers, which the agent is explicitly forbidden from choosing.
• Creating a scratch repo mutates the GitHub account.
• Creating and firing a routine writes to the claude.ai account and draws down metered subscription usage.
• The private arm requires creating a new private repo.

Related

• Blocks Tier 0 item 4 in docs/topics/boris-routines-adoption/PLAN.md (deferred question Q12, arbiter USER-RESERVED).
• Full evidence: .work/boris-routines-adoption/research/L2-harness-mechanics.md (follow-up section) on branch feat/boris-routines-adoption.

Secondary, cheap to fold in

pluginConfigs is read from user settings, --settings, and managed settings only — project-scope entries are ignored by design, "because a cloned repository must not be able to supply them." So any plugin in this fleet taking userConfig values has no repo-scoped way to receive them, and therefore no cloud-run way either. That holds regardless of how the spike resolves and may deserve its own issue.

[kyle-sexton]

Residual host note (cannot be substituted by cloud code alone)

This spike is operator/host-gated by design: it requires creating a routine on claude.ai, firing a one-off run, and reading the transcript (browser/account mutation). An agent cannot choose a connected Chrome browser or draw down metered routine usage unattended.

In-repo substrate already present: .claude/settings.json now declares enabledPlugins + SessionStart bootstrap (#2655), and Melodic env hash coverage for Python 3.11 (#2657). Those are necessary but not sufficient to answer the marketplace-load contradiction.

What remains for the human: run the issue's scratch-repo experiment (public arm; private arm if auth matters) and record whether repo-declared marketplace plugins resolve in a cloud routine transcript. Until that empirical result lands, treat Tier 0 item 4 in docs/topics/boris-routines-adoption/PLAN.md as USER-RESERVED.

Reopen only when the host experiment result is ready to encode as docs/code.