Cline CLI v3.0.5 Shows Plugin Visibility Is Agent Runtime Governance
Plugin visibility sounds like a settings-panel nuisance. In a coding-agent runtime, it is closer to an access-control bug with better typography.
Cline CLI v3.0.5, published May 16, fixes two small-looking problems: plugin-provided tools and slash commands now show up in the CLI settings dialog after being hydrated through the sandbox, and those hydrated plugin tools plus config-reload options no longer disappear after a user toggles settings. That is the entire release note. It is also a useful snapshot of where coding agents are headed: away from single-purpose assistants and toward programmable runtimes where the hard product problem is not just “can the agent do the thing?” but “can the operator tell what the agent is allowed to do?”
Cline is not merely a VS Code sidebar anymore. Its CLI README says the command-line app shares its agent core with the VS Code extension, JetBrains plugin, and SDK, so plan/act modes, MCP servers, checkpoints, rules, skills, and provider configuration are meant to behave consistently across surfaces. The CLI supports interactive TUI sessions, one-shot prompts, NDJSON output for downstream tooling, headless CI/CD usage, native MCP, checkpoints with /undo, sub-agent spawning, cron and event-driven schedules, and chat connectors for Telegram, Slack, Google Chat, WhatsApp, and Linear. That breadth changes the meaning of a disappearing plugin tool.
The settings dialog is now part of the security model
In a traditional desktop app, a settings dialog that fails to show an installed extension is annoying. In an agent runtime, it is governance drift. Plugins and MCP servers are not cosmetic add-ons; they are how an agent reads files, searches code, calls APIs, runs domain-specific operations, and wires itself into the rest of the engineering system. If the sandbox has loaded a plugin-provided tool but the settings surface does not show it, the human is making approval decisions from a stale map.
That stale map gets riskier as Cline spreads across execution surfaces. A developer may enable a plugin in an IDE, run the CLI in headless mode in CI, trigger a scheduled job, or interact through a Slack connector. The same underlying agent core is supposed to carry consistent rules and tools across those modes. Consistency is valuable, but it is also unforgiving: if configuration reloads, toggles, or sandbox hydration produce a different visible capability set from the actual runtime capability set, the operator loses the ability to reason about authority.
This is the same lesson showing up across agentic coding infrastructure. MCP gateways need to authorize at the tool-call boundary, not just in the connector picker. Browser agents need per-domain visibility, not just a one-time extension permission prompt. CLI agents need approval modes that reflect what can actually happen. Cline’s v3.0.5 fix lives in that family. It is not glamorous, but it is the sort of bug that separates a demo tool from something teams can operationalize.
The release also lands against a project with real gravity: during research, the Cline repository showed roughly 61,891 stars, 6,439 forks, 880 open issues, Apache-2.0 licensing, and a TypeScript codebase described as an “Autonomous coding agent as an SDK, IDE extension, or CLI assistant.” Stars are not a production-readiness certificate, but the combination of SDK, IDE, CLI, MCP, skills, schedules, webhooks, GitHub events, slash commands, and production packaging tells you the category has moved beyond “chat plus file edits.”
Extension ecosystems arrive before extension governance
The uncomfortable pattern is that agent platforms are becoming extensible faster than most teams are becoming good at governing extensions. Plugins, skills, slash commands, MCP servers, scheduled automations, webhook triggers, and provider profiles all increase leverage. They also increase the number of places where authority can hide.
A plugin can inject a command that looks harmless but calls a sensitive internal API. An MCP server can add verbose schemas that bloat context and quietly expose more operations than intended. A slash command can encode workflow assumptions that are safe on a laptop and reckless in CI. A scheduled job can reuse credentials long after the human who created it forgot it exists. None of these are Cline-specific problems. They are runtime problems, and every serious coding-agent platform is going to inherit them.
The practical answer is not “ban plugins.” That is how teams end up with worse shadow tooling. The answer is to treat plugin capability as production configuration. Teams should be able to answer: what plugin is installed, what version is active, who enabled it, which tools and slash commands did it register, what sandbox hydrated it, what provider profile can use it, whether it runs in CI, and what happens when it is toggled off. If a settings panel cannot be trusted as a source of truth, the control plane is decorative.
Cline’s sandbox detail is worth lingering on. Hydrating plugin tools through the sandbox is the right shape because the sandbox is where runtime authority should be mediated. But the UI has to reflect that mediated state, not a cached guess from before reload. In distributed agent systems, the live capability set is the product. Users do not need perfect internals, but they do need a truthful inventory.
For practitioners evaluating Cline or any similar agent runtime, the rollout test should be deliberately boring. Install a plugin. Expose one custom tool. Confirm it appears in the settings dialog. Toggle it off. Reload config. Switch from interactive mode to headless JSON. Run a scheduled job in a disposable repo. Confirm the tool is visible where it should be, absent where it should be, and denied when disabled. Then inspect logs. If this sounds like QA for enterprise software rather than playing with an AI assistant, that is the point. Coding agents are becoming enterprise software with shell access.
The sharp take: Cline v3.0.5 is a governance release disguised as a patch. The fix is small because the bug is small. The implication is not. Once agents can be extended, the settings surface is no longer a preference pane. It is the operator’s map of what hands the agent has.
Sources: Cline CLI v3.0.5 release, Cline CLI README, Cline SDK docs, Cline plugin docs, Cline tools docs