Enable CLINE_PLUGIN_MODE=sandbox to keep plugin subprocess isolation
Cline SDK v0.0.93 loads plugins in-process via one registry per process, so the compiled CLI needs no node/bun on PATH. Set CLINE_PLUGIN_MODE=sandbox to restore the subprocess sandbox, then use plugins.list/status/reload and session.create pluginIssues so a failed plugin no longer silently drops tools.Why this loop
Plugins used to spawn a node/bun subprocess. They now import in-process through a single registry, with timeouts and error capture around import, setup, hooks, tools, and commands, and explicit states (loading/ready/degraded/failed/disabled) plus last error. That unblocks the compiled CLI and lets plugins see the Bun global on the Bun-built hub, but plugin code shares the hub process unless you opt back into sandboxing. A failing plugin no longer disappears quietly: session.create takes a plugins policy and returns pluginIssues, later failures become session status notices, the hub serves plugins.list, plugins.status, and plugins.reload and broadcasts plugin.status_changed, and the daemon marks the plugin failed instead of exiting. Each session still gets its own copy of every plugin module, so module-level per-session state keeps working. Teams that run untrusted or third-party plugins should pin CLINE_PLUGIN_MODE=sandbox. Everyone else should wire pluginIssues and plugins.status into session startup so degraded plugins are visible instead of missing tools.
Proposed actions
- export CLINE_PLUGIN_MODE=sandbox before starting the Cline hub or compiled CLI so plugins keep loading in a node/bun subprocess instead of the hub process.
- When calling session.create, pass a plugins policy and read pluginIssues; treat failed/degraded/disabled plus last error as the reason a plugin's tools are missing, not as an uninstall.
- After installing or changing a plugin, call hub plugins.reload, then plugins.list and plugins.status; subscribe to plugin.status_changed so later failures arrive as session status notices instead of a daemon shutdown.
- If a plugin needs the Bun global, run the Bun-built hub with CLINE_PLUGIN_MODE unset; keep per-session plugin state at module level because each session already gets its own copy of the plugin module.
- Stop requiring node or bun on PATH solely to load plugins in the compiled CLI; in-process loading is the default whenever CLINE_PLUGIN_MODE is not sandbox.
Agent prompt
Paste into your agent or query via MCP (get_agent_prompt) — free, no extra AI costCline / .clinerules task
DevAgentRadar → Cline
You are helping me adopt a real coding-assistant change. Work only from the facts below. Do not invent features.
Context
Assistant: Cline Proposal: Enable CLINE_PLUGIN_MODE=sandbox to keep plugin subprocess isolation Summary: Cline SDK v0.0.93 loads plugins in-process via one registry per process, so the compiled CLI needs no node/bun on PATH. Set CLINE_PLUGIN_MODE=sandbox to restore the subprocess sandbox, then use plugins.list/status/reload and session.create pluginIssues so a failed plugin no longer silently drops tools. Primary source: https://github.com/cline/cline/releases/tag/sdk/sdk/v0.0.93
Why it matters
Plugins used to spawn a node/bun subprocess. They now import in-process through a single registry, with timeouts and error capture around import, setup, hooks, tools, and commands, and explicit states (loading/ready/degraded/failed/disabled) plus last error. That unblocks the compiled CLI and lets plugins see the Bun global on the Bun-built hub, but plugin code shares the hub process unless you opt back into sandboxing. A failing plugin no longer disappears quietly: session.create takes a plugins policy and returns pluginIssues, later failures become session status notices, the hub serves plugins.list, plugins.status, and plugins.reload and broadcasts plugin.status_changed, and the daemon marks the plugin failed instead of exiting. Each session still gets its own copy of every plugin module, so module-level per-session state keeps working. Teams that run untrusted or third-party plugins should pin CLINE_PLUGIN_MODE=sandbox. Everyone else should wire pluginIssues and plugins.status into session startup so degraded plugins are visible instead of missing tools.
Suggested actions
- export CLINE_PLUGIN_MODE=sandbox before starting the Cline hub or compiled CLI so plugins keep loading in a node/bun subprocess instead of the hub process.
- When calling session.create, pass a plugins policy and read pluginIssues; treat failed/degraded/disabled plus last error as the reason a plugin's tools are missing, not as an uninstall.
- After installing or changing a plugin, call hub plugins.reload, then plugins.list and plugins.status; subscribe to plugin.status_changed so later failures arrive as session status notices instead of a daemon shutdown.
- If a plugin needs the Bun global, run the Bun-built hub with CLINE_PLUGIN_MODE unset; keep per-session plugin state at module level because each session already gets its own copy of the plugin module.
- Stop requiring node or bun on PATH solely to load plugins in the compiled CLI; in-process loading is the default whenever CLINE_PLUGIN_MODE is not sandbox.
Config surfaces this release may change
- skills (high confidence) — check your repo before applying
After you finish
Do not report this as applied to DevAgentRadar. You cannot write the visitor's loop.
Tell the human: open https://devagentradar.com/proposals/cline-sdk-sdk-v0-0-93-enable-cline-plugin-mode-sandbox-to-keep-plugin-su and mark Applied, Skipped, or Failed. Proposal id: 94971ab6-afc8-4004-b15d-f6592b3e324c
Your job
- Restate the change in one sentence.
- Propose a minimal plan for my repo (or a throwaway pilot).
- Implement only what I approve; prefer small diffs and tests.
- Call out risks (permissions, breaking APIs, cost).
Start by confirming you understood the proposal.
Your loop
This browser · no sign-in · not shared as “you”After you run the prompt
Only you can mark this. Agents cannot write your loop.
Your decision stays on this device. A public tally appears after a few votes.