Plooms Code
Plooms Code is an AI coding agent for VS Code and Cursor, powered by Plooms and the top GLM and Kimi coding models. It plans, writes, and refactors code across your repo, runs terminal commands, connects to MCP servers and GitHub, and orchestrates a team of specialized subagents.
Requirements — please read before installing
Plooms Code runs entirely on your own Plooms instance. There is no bundled free tier, trial key, or sign-up flow. To use it you need:
- A Plooms inference endpoint (OpenAI-compatible) — e.g.
https://<your-tenant>.plooms.ai/api/inference/v1
- A Plooms Inference API key for that instance (Plooms → Settings → Inference API)
On first run the extension asks you to connect, and it will not run until it can reach your endpoint. If you don't have a Plooms instance yet, visit spej.ai first — the extension won't do anything useful without one.
Highlights
- Plooms-native — connects directly to your own Plooms endpoint (OpenAI-compatible). Your key is validated on entry and stored in your editor's encrypted secret storage.
- Four curated coding models, in the order the picker offers them
GLM 5.3 Flash — fast coding, and the default
GLM 5.2 — flagship coding
Kimi K3 — flagship coding
Kimi K2.7 Code — coding-optimized, always-thinking agentic model
- Repo-aware editing — reads, writes, and refactors files with reviewable diffs.
- Full command line — runs terminal commands like Claude Code / Codex.
- Plan / Confirm / Auto — plan read-only first, approve each action, or let it run autonomously.
- Project Manager + subagents — an Orchestrator decomposes your request and delegates to Coder, Designer, and Tester subagents.
- MCP built in — GitHub and Playwright servers preconfigured; add your own.
- Independent security review — an auditor model cross-checks the code before you ship it (see below).
Setup
- Install Plooms Code in VS Code or Cursor.
- Run Plooms Code: Connect to Plooms (or open Plooms Code in the activity bar) and enter your base URL and API key. Both are validated against your instance before they're saved.
- Start building — GLM 5.3 Flash is selected by default; switch models any time from the picker.
Both values can also come from the environment (PLOOMS_BASE_URL, PLOOMS_API_KEY). A GitHub token (GITHUB_PERSONAL_ACCESS_TOKEN) activates the GitHub MCP server automatically.
Modes
| Mode |
Behavior |
| Plan |
Investigates freely, changes nothing. Read-only commands run with no prompt — gh api against a private repo, curl, az / aws / gcloud / kubectl, docker, read-only git. Anything that writes, installs, or alters state is refused outright, and anything it doesn't recognise asks you first. |
| Confirm |
Executes, asking your approval for each edit / command / browser action. |
| Auto |
Runs autonomously with auto-approve enabled. |
Plan mode is a restriction on changing, not on running. It will not edit files (other than the
plan itself), write through a shell redirect, install packages, or run mutating git. Interpreters
(python, node, ruby, sh -c) are refused whatever they would do, because nothing can verify
their program before it runs.
A command that is neither a known reader nor a known writer — terraform plan, make, pytest, your
own CLI — asks you rather than running. No list of dangerous commands is ever complete, so the
unknown case goes to a human instead of being assumed safe. Approving one saves a narrowed rule, so
allowing kubectl get pods permits kubectl get * and never kubectl delete; approvals can't lift
a refusal, which is why the mutation guards stay put however long your allowlist grows.
Sandboxing, and Windows
Plooms Code contains the commands it runs using an OS sandbox: seatbelt on macOS and
bubblewrap on Linux. There is no Windows backend, so on Windows nothing contains a command —
the mode rules above are enforced by inspecting the command, which is a strong speed bump rather than
a boundary.
WSL2 gives Windows users a real sandbox, with no extra configuration. Open the folder in a WSL
remote window and Plooms Code runs Linux-side, where bubblewrap applies:
- Install WSL2 if you do not have it —
wsl --install in an admin PowerShell, then reboot.
(Microsoft's guide)
- Install bubblewrap inside the distribution:
sudo apt install bubblewrap.
- Install the WSL extension for VS Code (
ms-vscode-remote.remote-wsl).
- Keep the repository in the Linux filesystem —
~/code/project, not /mnt/c/.... Working
across the /mnt/c boundary is very slow, and that alone makes the setup feel broken.
- Reopen the folder in WSL (Reopen in WSL, or the green corner button).
Plooms Code prompts once on Windows to point this out, and takes "Don't show again" permanently.
None of it is required: if your project is Windows-native — .NET, PowerShell modules, MSVC, or a
Windows-only SDK — stay on Windows and ignore the notice.
Project instructions — pcode.md
Put a pcode.md in your repo to tell Plooms Code how to work in that project: conventions, commands, architecture notes, things to avoid. It carries the same authority for Plooms Code that CLAUDE.md carries for Claude Code, and it is read on every request.
Plooms Code looks for pcode.md first, then falls back to AGENTS.md and CLAUDE.md, so an existing repo keeps working unchanged — and a repo with a pcode.md is governed by it. A global pcode.md in your Spej config directory applies to every project.
scode.md was the name before 1.4.2 and is still read, just after pcode.md. Rename it when convenient; nothing breaks if you don't.
Plans and prompt history
Plooms Code keeps a running record of what you asked for in a plans/ folder at the project root, so you can see what happened and when:
- Normal work appends to one file per day —
plans/YYYY-MM-DD-<description>.md
- Plan mode gets its own file for that piece of work, using the same naming
- Finished plans are written to the same folder, beside the prompts that produced them
When a plan is done and you move on to new work, entries go back to the daily file.
Independent security review
To cross-check the code it writes, Plooms Code can run an independent auditor — Google Gemma 4, on your own Plooms instance — over your changes, looking for backdoors, data exfiltration, injected network calls, and malicious dependencies. The auditor is deliberately a different model family from whichever one wrote the code.
Run Plooms Code: Review Changes (working tree) or Plooms Code: Review Staged Changes (pre-commit). Findings appear in the Plooms Security Review output panel and are written to a local audit log. The review is on-demand and never blocks your work.
Useful commands
| Command |
What it does |
| Plooms Code: Open |
Open Plooms Code in the editor and focus the composer |
| Plooms Code: Connect to Plooms |
Enter / change your endpoint and API key |
| Plooms Code: Show Plooms Connection |
Verify exactly which endpoint and key are in use |
| Plooms Code: Review Changes |
Run the independent security review |
| Plooms Code: Open Logs |
Open the engine and inference logs |
| Plooms Code: Show Version |
Show the installed extension and engine versions |
Privacy
Your code and prompts go to your Plooms endpoint — the one you configure. Spej does not proxy your inference traffic. Your API key is held in your editor's secret storage and is never written to the extension's logs (the logs record only a masked fingerprint, so you can confirm which key was used).
Plooms Code is a modified derivative of Kilo Code (built on opencode), used under the MIT License. Copyright © the Kilo Code contributors. The full upstream license and attribution ship with this extension in LICENSE and NOTICE.