Cline SDK v0.0.94 Released: Plugin Isolation and Retry Mechanism Upgrades

Cline's SDK has received its v0.0.94 update. Although the version number bump is modest, this release makes a number of substantive adjustments to the plugin execution mechanism, error retry strategy, and model catalog—especially the tightening of plugin security boundaries, which deserves developers' attention.

Plugin Execution Modes Tightened Across the Board

The most notable change in this update is the adjustment to the plugin execution environment. Plugins now run only in worker threads (the default, CLINE_PLUGIN_MODE=worker) or in a child-process sandbox (sandbox). The previous in_process mode has been completely removed, along with the silent fallback mechanism it once retained.

What does this mean? In the past, if a host hadn't correctly configured the plugin sandbox, plugins could quietly run inside the hub process. While this "safety net" behavior was convenient, it planted hidden risks for stability and security. Now, if the host doesn't provide plugin-sandbox-bootstrap.js, every plugin load will fail and throw a PluginBootstrapMissingError, with the error message explicitly pointing to the CLINE_PLUGIN_BOOTSTRAP_PATH environment variable.

The hub daemon's uncaught error handler has also reverted to fatal level, no longer silently swallowing exceptions. You may not have noticed, but the SSH remote hub currently doesn't ship with a bootstrap, so it will report plugin tools as missing. For teams relying on SSH remote collaboration, this may cause short-term inconvenience.

The difference between worker threads and child-process sandboxes is the prerequisite for understanding this change. Worker threads share the same process memory space but have an independent JavaScript execution stack and event loop, with low startup overhead and low communication cost—suitable for plugins with a relatively high level of trust that need to exchange data with the host frequently. A child-process sandbox, on the other hand, places the plugin in a separate OS process with its own memory space and privilege boundary, so even if the plugin crashes or oversteps its permissions, it's less likely to affect the main hub process—at the cost of higher process creation and IPC serialization overhead. The CLINE_PLUGIN_MODE environment variable is precisely what lets the host make an explicit choice between these isolation levels, rather than relying on plugins to decide for themselves.

Why in_process mode is dangerous: Executing plugin code directly in-process means the plugin shares the same V8 context, the same global state, and the same filesystem and network permissions as the hub. Any uncaught exception, memory leak, infinite loop, or even malicious code in a plugin will directly affect the host itself. The previous silent fallback mechanism had an even more insidious problem: it led the host to believe it was in an isolated state when it was actually running in a non-isolated environment, causing security audits and troubleshooting to draw incorrect conclusions. Removing this fallback effectively turns an "implicit security assumption" into an "explicit startup failure," so that a missing configuration is exposed at the first opportunity.

How to handle PluginBootstrapMissingError: plugin-sandbox-bootstrap.js is the bootstrap script the host prepares for the plugin's sandbox runtime. It's responsible for initializing the isolated environment and exposing a restricted API to the plugin. CLINE_PLUGIN_BOOTSTRAP_PATH is used to tell Cline where that script is located. If you see this error in a self-built host or CI environment, you need to confirm that the environment variable is set, that the path is accessible to the hub, and that the bootstrap script matches the SDK version. For the SSH remote hub, since it currently doesn't ship with a bootstrap, plugin tools will be reported as missing—teams relying on remote plugin capabilities need to assess whether this limitation is acceptable.

More Granular Model Stream Retry Strategy

At the model interaction level, v0.0.94 refines error handling. When a Provider error is received after a model stream has already started, it will now be retried up to 3 times, and a final failure will be logged to logs and Langfuse traces.

The more critical change is this: once the retry count is exhausted, the agent's full-round retry is no longer triggered on top of it. This change avoids the "multiplication effect" of the retry budget—previously, stacking the two could cause requests to be repeatedly amplified, wasting resources and time. At the same time, logs for failed model requests now include the Provider's request id, making troubleshooting easier.

What the "multiplication effect of the retry budget" is: Suppose a user request triggers a model stream. If the stream fails internally, it's retried up to 3 times, and the agent then reinitiates the whole round after a full-round failure—so a single call could actually generate 3 × 3 = 9 or even more upstream requests. If the request is doomed to fail due to rate limiting, billing, or network issues, this stacking only multiplies the load and cost, and floods the logs with duplicate records. The significance of distinguishing "stream-level retries" from "agent-level retries" is that the former targets recoverable transient failures such as network jitter or temporary Provider 5xx errors, while the latter targets the failure of an entire task plan. Their trigger conditions and costs are completely different, and mixing them together means losing control over the number of retries.

The role of Langfuse traces and request id: Langfuse is an observability tool for tracing call chains in LLM applications. It records each model request, retry, latency, and error as a searchable trace. Writing final failures into traces means developers can replay the failure path afterward by session or request dimension, rather than just seeing a vague error log. The Provider's request id is generated by the upstream service and is the unique credential for filing a ticket or reconciling with the Provider. Logging it significantly shortens the time from "user reports a failure" to "pinpointing the specific upstream request."

Improvements to Embedded Hosts and Remote Connections

For developers embedding Cline into their own products, this update provides several convenient entry points. The new setHubDaemonLauncher allows an embedded host to launch the hub daemon via a bundled Cline CLI; ensureDetachedHubServer adds a beforeSpawn hook that runs only when a new daemon is actually being started.

The standalone SSH remote auxiliary entry point has been removed; SSH remote now runs the hub via an uploaded Cline CLI. NodeHubClient now accepts resolveConnectionHeaders, so the remote proxy's WebSocket upgrade can authenticate with HTTP headers refreshed on each reconnection—this capability flows through both HubRuntimeHost and RemoteRuntimeHost.

Additionally, AskQuestionExecutor can now return text and image blocks, so attachments sent along with answers actually reach the model. A new buildTelemetrySelfcheckReport export has been added to @cline/shared.

The purpose of setHubDaemonLauncher and the beforeSpawn hook: When Cline is embedded into an IDE, desktop app, or other product, the host often already ships with its own copy of the Cline CLI and wants to use it directly to spin up the hub daemon, rather than relying on a separately installed version on the system. setHubDaemonLauncher is exactly the injection point provided for this purpose. ensureDetachedHubServer is responsible for ensuring a hub detached from the current process is running. The newly added beforeSpawn hook fires only when a new daemon genuinely needs to be created, letting developers complete port allocation, environment variable injection, or log directory preparation before startup, without worrying about the hook being falsely triggered when an existing hub is reused.

The authentication problem resolveConnectionHeaders solves: The remote proxy's WebSocket upgrade needs to carry authentication information, but tokens often have an expiration time. If the request headers are only read once at connection time, reconnections will use expired credentials. resolveConnectionHeaders allows HTTP headers to be recalculated on each reconnection, thereby supporting dynamic authentication schemes like token refresh and signed timestamps. This capability is kept consistent across HubRuntimeHost and RemoteRuntimeHost, reducing the debugging cost caused by behavioral divergence between local and remote.

Major Overhaul of the Model Catalog and Default Models

The model catalog has been refreshed from 6,862 to 6,952 entries. Two new Providers have been added, Boundless and Standard Compute; SambaNova is now sourced from the catalog, with a default model of MiniMax M3.

The Cline recommended list adds Gemini 4 Argon and removes Grok 4.7; the free list replaces Step 5 Preview with Nemotron 3.5 Super VL. OpenCode Go no longer lists MiniMax M2.7.

Quite a few Providers have had default model changes: Cortecs, CrossModel, Eden AI, Google Gemini, GitHub Copilot, Google Vertex AI, LLM Gateway, Ofox, OpenCode Go, and Prime Inference now default to Gemini 4 Argon; Fireworks AI, Nebius Token Factory, and Requesty move to Muse Spark Open; CoreWeave, DigitalOcean, NanoGPT, and Nvidia adopt Nemotron 3.5 Super VL; Aixy and Neon use Claude Haiku 5.5; Agnes AI, Ambient, IteraCompute, Poe, Scaleway, and SenseNova also have their own adjustments. In addition, the bundled default model for the cline provider has switched from Claude Sonnet 5.5 to Gemini 4 Argon, because the recommended list now leads with it.

The relationship between the model catalog and "default models": The model catalog is a centralized list containing each Provider's available models, context windows, pricing, and capability flags. Cline uses it to validate whether a user-configured model exists and to render the selectable list accordingly. The default model, meanwhile, is the one actually invoked when neither the user nor the project explicitly specifies a model. Therefore, catalog refreshes and default value changes affect two different groups of people: the former affects what can be selected, while the latter affects what gets used when nothing is configured. Entries like Gemini 4 Argon, Muse Spark Open, Nemotron 3.5 Super VL, and Claude Haiku 5.5 represent different vendors' positioning in general reasoning, open weights, multimodality, and lightweight low-cost directions, respectively. When a Provider switches its default, it's usually re-weighing cost, latency, and quality.

Why regression validation is essential after upgrading: Default model changes won't modify the explicit configuration in your code, but they will silently change the output on all call paths where "no model is specified." Different models differ in instruction following, output format, tool-calling style, and context length. In particular, workflows that rely on structured output or strict JSON parsing may fail to parse due to changes in a model's phrasing habits. It's recommended to map out all locations in your project that implicitly depend on the default model before upgrading, run end-to-end tests on those paths after upgrading, and explicitly pin the models for critical paths where necessary, to avoid being unexpectedly affected by future catalog refreshes.

Practical Impact on Developers

The core signal of this update is clear: Cline is turning the security boundary for plugin execution from "best effort" into "enforced constraint." If your host environment isn't yet prepared with plugin-sandbox-bootstrap.js, plugins will simply be unavailable after upgrading. It's recommended to confirm the path configuration for the sandbox bootstrap file before upgrading.

The broad adjustments to model defaults also mean that if your project depends on specific default models, you'll need to re-validate whether the output meets expectations after upgrading. Overall, v0.0.94 is a release leaning toward stability and security, suitable for teams with plugin isolation requirements to adopt as soon as possible.

One-line Summary

Cline SDK v0.0.94 tightens plugin sandboxing, refines retries, and overhauls default models.

Paragraph Summary

Cline SDK v0.0.94 is an update leaning toward stability and security. The most core change is the tightening of plugin execution modes: in_process mode, along with the silent fallback mechanism, has been completely removed, and plugins can now run only in worker threads or child-process sandboxes. When a host lacks plugin-sandbox-bootstrap.js, it will directly throw PluginBootstrapMissingError; the hub daemon's uncaught error handler has also been restored to fatal level, and the SSH remote hub currently doesn't ship with a bootstrap, so plugin tools will be reported as missing. At the model interaction level, a model stream that has already started will retry up to 3 times on Provider errors, with failures written to logs and Langfuse traces, and no longer stacked with agent full-round retries, avoiding multiplicative amplification of the retry budget. Embedded hosts gain setHubDaemonLauncher and a beforeSpawn hook, while NodeHubClient supports refreshing authentication headers on each reconnection. The model catalog has been refreshed from 6862 to 6952, adding Boundless and Standard Compute; Cline's bundled default model has switched from Claude Sonnet 5.5 to Gemini 4 Argon, and many Providers' default models have been adjusted in sync.