Pluripo

An agentic coding assistant for VS Code. Pluripo runs an AI agent inside your editor that can read, search, and edit files across your workspace, run shell commands through a terminal tool, and optionally fetch documentation from the web — all with approval prompts so you stay in control of what it does.

Learn more at pluripo.com.

Early access

Pluripo is in early access and ships as a pre-release extension. Creating an account currently requires an invite link — if you have one, open it in your browser to sign up. Without an invite, sign-in will tell you that sign-ups are not yet open.

Getting started

Install Pluripo from the VS Code Marketplace.
Open the Pluripo view from the activity bar (the Pluripo icon on the left).
Run Pluripo: Sign In from the Command Palette and complete sign-in in your browser.
Type a request in the chat panel and let the agent work. You'll be asked to approve file edits and shell commands as they happen.

Useful commands (Command Palette → search "Pluripo"):

Pluripo: Open Chat — prompt for a request and run it.
Pluripo: New Chat — start a fresh session.
Pluripo: Show Third-Party Notices — attribution for bundled open-source dependencies.
Pluripo: Sign Out / Pluripo: Delete Account — manage your account.

Trusted vs. untrusted workspaces

In an untrusted workspace Pluripo runs in read-only mode: only the read, glob, grep, and list-directory tools are available to the agent. The write, edit, terminal, and web-fetch tools stay disabled until you grant the workspace trust.

Settings

All settings live under pluripo.* and appear in the VS Code Settings UI under Extensions → Pluripo, each with an inline description. Highlights:

pluripo.security.allowedPathsOutsideWorkspace — extra directories file tools may touch.
pluripo.security.commands.alwaysAllow / alwaysDeny — auto-approve or block matching shell commands.
pluripo.security.webPolicy.* — controls for the webfetch tool (see below).
pluripo.checkpoint.mode — how the workspace is snapshotted before each prompt so a turn can be reverted.
pluripo.telemetry.enabled — send anonymous product telemetry (counters and durations only — never file paths, prompts, or tool arguments).

Web access

Pluripo includes a single web tool, webfetch, that lets the agent read a public URL and work with its contents (HTML pages are converted to Markdown). The first time the agent fetches from a new domain in a session, Pluripo asks you to approve it — you can allow it once, allow and remember it, or deny.

By default webfetch only reaches public web addresses; private and internal network addresses are blocked. If you need the agent to read from a self-hosted docs site, or you want to restrict fetching to an explicit allowlist, use the pluripo.security.webPolicy.* settings — each has an inline description in the Settings UI.

Connecting tool servers (MCP)

Pluripo can connect to external tool servers that follow the Model Context Protocol (MCP) — the same open standard other AI coding tools use. A tool server can give the agent extra abilities (for example, talking to your issue tracker), share files as context, and offer ready-made prompts.

You set up servers in a file at .pluripo/mcp.json in your project. It uses the same mcpServers format other MCP tools use, so an existing config carries over. The file is plain JSON — no comments, since it is read with a strict parser. There are two kinds of server. A local program Pluripo starts on your machine (my-local-server below), and a remote server reached over the web (my-remote-server):

{
  "mcpServers": {
    "my-local-server": {
      "command": "my-server-binary",
      "args": ["--flag"],
      "env": { "API_KEY": "..." }
    },
    "my-remote-server": {
      "type": "http",
      "url": "https://example.com/mcp",
      "headers": { "Authorization": "Bearer ..." }
    }
  }
}

Each server also accepts a few optional keys to keep things focused:

"enabled": false — turn a server off without deleting its entry.
"enabledTools": ["a", "b"] — only allow these tools from the server (everything else stays hidden, which keeps the agent fast and on-task).
"disabledTools": ["c"] — block specific tools while allowing the rest.
"readOnlyInPlanMode": true — let this server's non-destructive tools be used while the agent is planning (plan mode only runs read-only tools). Without it, a server's tools are available during planning only if the server itself marks them read-only.

You're always asked before a server is used. The first time a server is needed, Pluripo asks for your approval and remembers your choice. For a local server it warns that approving will run a program on your computer; for a remote server it shows you the web address it will connect to. Just opening a project that contains an .pluripo/mcp.json never starts anything on its own. A remote server may also ask you to sign in through your browser the first time.

Once a server is connected:

Its prompts appear in the chat as slash commands named /mcp__<server>__<prompt> — type / to see them.
Its files and data appear as @-mentions written @mcp:<server>/... — start an @ mention to pick one, and its content is pulled in only when you choose it.

You can see each server's status and reconnect or disconnect one any time from the Command Palette via Pluripo: Manage MCP Servers.

Lifecycle hooks

Pluripo can run your own shell commands at key moments while it works — for example, to block a risky command, ask you before something runs, or feed the agent extra context. These are called hooks, and the idea mirrors hooks in Claude Code and Cursor, so existing hook scripts mostly carry over.

You define hooks in a file at .pluripo/hooks.json in your project (sibling to .pluripo/mcp.json). It's plain JSON — no comments, since the file is read with a strict parser. A ready-to-copy example lives in this repo under docs/examples/hooks/: the hooks.json config plus the sample scripts it references. Copy them into your project's .pluripo/hooks.json and .pluripo/hooks/.

When hooks fire

Event	When	What it can do
`PreToolUse`	before a tool runs	block the call, ask you first, or add context
`PostToolUse`	after a tool runs	add context for the agent to read next
`UserPromptSubmit`	when you send a message	stop the turn, or add context to it
`SessionStart`	when a chat starts	add standing context for the session
`Stop`	when the agent finishes a turn	observe/notify, or ask it to keep working until a check passes
`SessionEnd`	when a chat is closed	run a side effect (cleanup, logging)

The config shape

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "bash|edit|write",
        "hooks": [
          {
            "type": "command",
            "command": "./.pluripo/hooks/guard.sh",
            "args": [],
            "timeout": 10,
            "failClosed": true
          }
        ]
      }
    ]
  }
}

matcher picks which tools (or, for SessionStart, which kind of start) the hook applies to. "*" or leaving it out means all; "a|b" means either a or b; anything else is treated as a regular expression. The name it matches is the raw tool name, so MCP tools (named mcp__<server>__<tool>) match too.
type is always "command" (shell commands are the only hook type today).
command is the program to run. With args present it runs directly (no shell, so nothing re-parses the input — the safest form); leave args out to run the whole string through your shell.
timeout (seconds) bounds how long the hook may run before it's stopped.
failClosed: true marks a gate: if the hook can't run (error or timeout), the tool is denied rather than allowed. Without it a hook is advisory — if it fails, the work just continues.

You can turn the whole feature off two ways: a top-level "enabled": false in hooks.json (team-wide, committed), or the VS Code setting pluripo.hooks.enabled (your machine only). Either one is a kill switch — no hook runs and no approval is asked. You can also set "enabled": false on a single entry to disable just that one.

How a hook makes a decision

Pluripo sends each hook a JSON object on standard input describing the moment — for a tool event that includes the tool name and its arguments; for a prompt it includes your text; for a session start it includes the kind of start.

The hook replies with its exit code, and optionally a JSON object on standard output:

Exit code	Meaning
`0`	Success. If the hook printed JSON on stdout, Pluripo reads it (below).
`2`	Block the tool call. Whatever the hook wrote to stderr becomes the reason shown to you and the agent.
anything else	A non-blocking error: a small notice appears and the work continues (unless the hook is `failClosed`).

The optional stdout JSON (every field is optional):

{ "permission": "allow" | "deny" | "ask",
  "agentMessage": "why",
  "additionalContext": "text for the agent to read",
  "continue": true }

permission — deny blocks (same as exit 2); ask routes the call to you for approval; allow simply defers to Pluripo's own security checks.
agentMessage — the reason shown alongside a deny/ask.
additionalContext — text the agent will read. For Pre/PostToolUse it's attached to that tool's result; for UserPromptSubmit/SessionStart it's added to the turn. (Injected text is clearly marked as coming from a project hook and is length-limited, so it can't quietly take over the conversation.)
continue — on a Stop hook, ask the agent to keep working instead of ending the turn (bounded so it can't loop forever).

A hook can only tighten things — never loosen them. It can block or ask, or add context, but it can't rewrite a tool's arguments and it can't override Pluripo's built-in security gate. When several hooks match the same moment, a single deny wins, and their injected context is combined.

Approving a hook (the safety model)

A hook is a program running on your computer with your access — the same risk as an MCP server. So just having .pluripo/hooks.json in a project never runs anything on its own. The first time a given hook would run, Pluripo shows a blocking approval prompt naming the exact command and warning that approving it lets the command do anything you can do — only approve hooks in workspaces you trust.

Your approval is remembered on your machine only — it's never written into the committed config, so cloning a repo can't pre-approve its hooks for you.
If a hook's command is edited, Pluripo asks again before the changed version can run.
Running in "approve everything" mode does not skip hook approval.

Managing and seeing hooks

Type / in the chat to reach two on-demand menus (there's no always-on panel):

/hooks — list the hooks the project defines with their status (trusted or needs-approval, enabled or disabled) and act on one: enable or disable it for yourself, trust or untrust it, run it once, or open .pluripo/hooks.json to edit.
/mcp — the same on-demand menu for your MCP tool servers.

In VS Code these also exist as Command Palette commands — Pluripo: Manage Hooks and Pluripo: Edit Hooks Config — and there's a settings toggle, pluripo.hooks.enabled. When a hook acts, you see it inline in the chat: a blocked tool shows a hooks badge with the reason, an "ask" shows an approval card, and injected context or a kept-going turn shows a short note saying it came from a project hook.

Parallel sessions (worktrees)

This is internal tooling for developing Pluripo itself — not part of the shipped extension. To run several interactive coding sessions (Claude, Codex, or both) against this repo at once, give each one its own git worktree: an isolated checkout on its own branch, in a sibling directory. The sessions never touch the same files, and each one ships its own work to main when it's green (via the /ship command).

You are the coordinator: open one panel per worktree and hand each a disjoint scope so two sessions don't edit the same area. The branch name encodes the area (work/<task>), which keeps the parallel work easy to track.

scripts/worktree.sh handles the setup and teardown:

# Start a session for an area of work. Creates ../pluripo-worktrees/chat-ui on
# branch work/chat-ui off the latest origin/main and runs `pnpm install` to give
# it its own node_modules (fast — pnpm hardlinks from its global store). Secrets
# resolve through 1Password (op run) over the committed backend/.env.op.dev
# template; pass --copy-plaintext-env to copy local .env / .env.dev in instead.
bash scripts/worktree.sh new chat-ui

# …then in that directory, run an interactive session:
#   cd ../pluripo-worktrees/chat-ui
#   claude        # or: codex

# List all active worktrees.
bash scripts/worktree.sh list

# Clean up when the work has landed. Refuses if the worktree has uncommitted
# changes or the branch isn't merged into origin/main yet — it never deletes
# unmerged work.
bash scripts/worktree.sh done chat-ui

<task> is a short slug for the area (letters, digits, -, _, .; no slashes or spaces).

Claude Code's built-in claude --worktree is an equivalent alternative if you'd rather it manage the worktree for you; worktree.sh is the thin shared version that also runs the per-worktree pnpm install and seeds the 1Password env reference.

Support

Questions, bug reports, or feedback? Reach us at pluripo.com/contact.

Legal

Pluripo is closed-source. Bundled open-source dependencies and their licenses are listed in the third-party notices file included with the extension, which you can view any time from the Command Palette via Pluripo: Show Third-Party Notices.