Claude Code plugins are not available in fullsend sandbox containers

[gklein]

fullsend agents running inside OpenShell sandbox containers cannot use Claude Code plugins. The sandbox has restricted network access, so Claude Code cannot download plugins from the marketplace at runtime. No plugin binaries or configurations exist in the container image.

There is no mechanism in the harness YAML to declare which plugins an agent needs, and no infrastructure to pre-install plugins in the container image for offline use.

[fullsend-ai-triage]

RICE Priority Score: 0.75

Score breakdown

Dimension	Score	Reasoning
Reach	2	This is a platform-wide architectural limitation: all fullsend agents running in OpenShell sandbox containers are affected if they need Claude Code plugins. Since sandboxed execution is the default runtime model, this potentially blocks plugin adoption for all users including strategic customers (konflux-ci, openkaiden, guacsec). However, the issue was filed internally by gklein, and no strategic customers have reported it yet, suggesting plugin usage may not be an immediate need for them.
Impact	1.5	Plugins are entirely unavailable in sandboxed containers with no workaround — agents simply cannot use them. This blocks a whole category of Claude Code functionality (plugins) in the primary execution environment. Scored as a significant pain point rather than critical because core agent functionality still works without plugins.
Confidence	0.5	Medium confidence. The technical problem is clearly described and well-scoped, but there is significant uncertainty about actual demand: no strategic customers have requested plugins yet, no comments exist on the issue, and it's unclear how many current or near-term workflows depend on plugin availability in sandboxes.
Effort	2	This requires multiple coordinated changes: extending the harness YAML schema to declare plugin dependencies, building infrastructure to pre-install plugin binaries into container images (likely a build-time step), and potentially handling offline plugin configuration. Touches the harness spec, container build pipeline, and possibly the agent runtime — a complex, multi-component effort.

Formula: (2 × 1.5 × 0.5) / 2 = 0.75

[ralphbean]

What plugins do you want to use?

[ralphbean]

FWIW, I'm hesitant about Claude Code plugins in general b/c they tie us down to Claude Code as a singular agent runtime. Although we currently only support Claude Code, I'd like to someday support goose and opencode as alternatives - in part just to ensure we don't lock ourselves into a single vendor unnecessarily.

That doesn't mean we can't support claude code plugins.

[gklein]

What plugins do you want to use?

I am looking for LSP support Pyright/Gopls so we can integrate QualityFlow.

[guyoron1]

Following up on @gklein reply — we need gopls/pyright for QualityFlow, our agentic QE pipeline that traces call graphs from code changes for regression impact analysis.

Working solution: gopls CLI

We got gopls working inside FullSend sandboxes by calling it directly via Bash (e.g. gopls symbols, gopls references, gopls definition). No Claude Code plugin infrastructure needed.

Same engine as the persistent language server — same type checker, same index, same results. Each command starts a fresh process, which is slightly slower but works reliably in the sandbox.

Changes needed in fullsend:

images/code/Containerfile — install gopls + the Go toolchain. For Python: npm install -g pyright (Node.js is already in the image).

internal/cli/run.go — in bootstrapEnv(), include /usr/local/go/bin in the PATH export. Without this, gopls fails with go command required, not found because Claude Code's Bash tool spawns shells that don't inherit Docker ENV PATH or the fullsend .env file.

The CLI approach is runtime-agnostic — if fullsend adds goose or opencode support, they'd call the same CLI commands. No vendor-specific plugin system required.

[gklein]

Closing now that #815 is merged