Cline CLI v3.0.72 Released: Plugin Sandboxing and Major Model Catalog Update

Cline CLI has released version v3.0.72, bringing changes across plugin execution mechanics, network error retries, Hub command extensions, and a model catalog refresh. For developers who use Cline for AI-assisted coding on a daily basis, the change to plugin execution mode is the most important update to note.

Plugins Now Run in Worker Mode

Previously, Cline plugins ran directly inside the hub process, an architecture where a single plugin issue could affect the stability of the entire hub. v3.0.72 migrates plugins to run independently in workers, achieving process-level isolation.

More importantly, the error feedback mechanism has improved: if the current build cannot run plugins, Cline now clearly notifies the user through cline config tools, cline hub plugins, and a session startup warning, rather than silently running inside the hub as before. This explicit-failure design approach is commendable—it surfaces the problem to the user instead of letting them unknowingly use a degraded fallback.

Note that the CLINE_PLUGIN_MODE=in_process environment variable is no longer supported. Users can now only choose between worker (the default) and sandbox modes. If you have hardcoded in_process in CI scripts or local configuration, you'll need to adjust it after upgrading.

On Process Isolation and Worker Mode

In software architecture, process isolation is a common stability design technique. When a plugin runs inside the main process (here, the hub process), the plugin code shares the same memory space and event loop as the core logic—if the plugin crashes, leaks memory, or blocks the event loop, the entire hub is affected. Migrating plugins to run in workers means each plugin (or group of plugins) executes in a separate child process or worker thread, with the main process communicating via message passing. The benefits include: a reduced failure domain, recoverable crashes, and resource limiting. The costs are increased communication overhead and more complex debugging. Sandbox mode goes further by tightening permissions and filesystem access, making it suitable for scenarios with higher security requirements.

Automatic Retry for Interrupted Streaming Responses

AI coding tools frequently encounter temporary provider-side failures in real-world use. When a streaming response is interrupted mid-stream by a provider error, Cline now automatically retries up to 3 times, and only declares the conversation turn failed after exceeding that limit.

This change looks simple, but it has a significant impact on the actual coding experience. Previously, a single network hiccup could cause the entire response to be lost, requiring the user to resend the request and wait for the model to generate from scratch. The automatic retry mechanism alleviates this issue to some extent.

A companion improvement is that failed request logs now record the provider's request ID. For users who need to submit support tickets, this ID can significantly shorten the time to pinpoint the issue—a practical operational-friendly change.

The Significance of Streaming Responses and Request IDs

A streaming response refers to a model pushing tokens to the client incrementally during generation, rather than waiting for the complete result before returning. This approach can significantly reduce time-to-first-token and improve the interactive experience, but at the cost of a longer-lived connection that's more susceptible to network hiccups or temporary provider-side errors—if the connection drops mid-stream, the already-generated partial content may not be assembled. The automatic retry mechanism addresses exactly this "partial failure" scenario: the client detects the interruption and re-initiates the request, retrying up to a certain number of times, preventing the entire conversation turn from being wasted. A provider request ID is a unique identifier assigned by the server for each call, allowing support or engineering teams to precisely locate the issue in server-side logs—a key clue for diagnosing production failures.

Hub Command Capability Extensions

The cline hub ensure and cline hub start commands now support several useful parameters:

• --json: Outputs the hub URL and auth token directly, suitable for scripted invocation
• --allow-port-fallback: Allows port fallback, reducing startup failures due to port conflicts
• --no-connectors: Skips connector loading
• --login-shell-path: Specifies the login shell path

cline hub also supports the --discovery-path parameter, allowing the use of a separate discovery record. Additionally, the cline hub family of commands no longer counts toward CLI activation statistics—a change that teams tracking usage data should be aware of.

Scripted Invocation and CLI Activation Statistics

Parameters like --json matter because they make command output parseable by programs rather than only readable by humans. CI/CD, automation scripts, or IDE plugins can directly extract the hub URL and auth token without regex-parsing human-readable text, significantly improving integration reliability. --allow-port-fallback addresses the common deployment pain point of port occupation: when the default port is taken, it automatically tries a fallback port, preventing startup failures from interrupting workflows. As for "no longer counting toward CLI activation statistics," this means such command invocations won't be recorded as a CLI activation event, so usage data more accurately reflects how often developers actually use AI-assisted coding, rather than being polluted by background automated calls.

Model Catalog Refresh and Default Model Changes

This update features a fairly broad refresh of the model catalog. Two new providers were added, Boundless and Standard Compute; SambaNova is now fetched from the catalog, with MiniMax M3 as the default model.

On the Cline recommended list, Gemini 4 Argon was added and became the first model on the list, while Grok 4.7 was removed. The free list replaced Step 5 Preview with Nemotron 3.5 Super VL. OpenCode Go no longer lists MiniMax M2.7.

The providers whose default models changed span a wide range, including Cortecs, CrossModel, Eden AI, Google Gemini, GitHub Copilot, Google Vertex AI, LLM Gateway, Ofox, OpenCode Go, Prime Inference (all changed to Gemini 4 Argon), Fireworks AI, Nebius Token Factory, Requesty (Muse Spark Open), CoreWeave, DigitalOcean, NanoGPT, Nvidia (Nemotron 3.5 Super VL), Aixy, Neon (Claude Haiku 5.5), as well as Agnes AI, Ambient, IteraCompute, Poe, Scaleway, SenseNova, and others.

For users who haven't manually selected a model, the Cline provider now defaults to Gemini 4 Argon. If you depend on a specific model, it's worth checking whether your configuration is affected—default model changes can alter output quality and style without you noticing.

On the Model Catalog and Default Models

The model catalog is the centralized configuration an AI coding tool uses to enumerate available models, providers, and their metadata. By periodically refreshing the catalog, Cline brings newly launched providers and models into the selectable range while removing entries that are offline or no longer maintained. The default model is the one automatically used when the user hasn't explicitly specified one, and its changes often "silently" affect output quality, style, response speed, and cost—because most users don't manually switch every time. The recommended list, free list, and default model are three different tiers: the recommended list influences new users' initial choices, the free list determines the zero-cost usable range, and the default model directly affects existing users' daily calls.

Upgrade Recommendations

Upgrading from v3.0.71 to v3.0.72 is a routine iteration, but two types of users need to pay special attention: first, those who rely on CLINE_PLUGIN_MODE=in_process, as that mode has been removed; second, users sensitive to the default model, who should confirm after upgrading that the model currently in use meets their expectations. Overall, the core direction of this update is improving system stability and observability, and the plugin isolation and request retry changes are especially beneficial for production environments.

One-line Summary

Cline CLI v3.0.72 moves plugins to isolated worker execution, adds automatic retry for streaming responses, and broadly refreshes the model catalog.

Paragraph Summary

Cline CLI v3.0.72 is an iteration centered on stability and observability. The most notable change is the plugin execution mechanism: plugins migrate from running inside the hub process to independent workers, achieving process-level isolation while clearly informing users of plugin failures, and the CLINE_PLUGIN_MODE=in_process environment variable is no longer supported. Next are network-layer improvements: streaming responses interrupted by provider errors now retry up to 3 times, and failure logs record the provider request ID for easier troubleshooting and ticket submission. The Hub command adds parameters like --json, --allow-port-fallback, --no-connectors, and --login-shell-path, and no longer counts toward CLI activation statistics. The model catalog sees a broad refresh, adding Boundless and Standard Compute providers, adding Gemini 4 Argon to the recommended list and removing Grok 4.7, with default models for many providers adjusted accordingly; users who haven't manually selected a model will default to Gemini 4 Argon.