Pi Agent: The Trade-off Between Freedom and Convenience

1. The first surprise

That contrast is a statement about where the work sits, not about quality. In an integrated product, many supporting capabilities already exist when you open it. With Pi, I could change or build those pieces myself, and I started doing that.

This article follows one argument. Pi gives developers more freedom to shape the system around a model, and that freedom transfers responsibility to them. Convenience doesn’t disappear. It becomes something you build, integrate, test and maintain. I’ll go from the architecture and its tool system, through my experiments, to what happens when execution fails, the permission boundary, the workflow problem and Code Mode, then ask whether a bigger toolset would have fixed any of it, and end on what I think the trade-off is.

2. What Pi is

Four built-in tools are on by default: read, bash, edit and write. Four more built-ins (grep, find, ls and the Windows-only powershell) are opt-in (CLI reference). Section 3 covers the whole tool system. The homepage lists what Pi deliberately leaves out: “No sub-agents”, “No plan mode”, “No permission popups”. For each it points to extensions, packages, or other tools instead (pi.dev).

The loop itself is small. Pi appends your message to the active branch, builds a request from the system prompt, the branch, the tool definitions and the model settings, streams the reply, runs every tool call in it, and records the results. If those results or queued messages need another request, a new turn starts. Otherwise the run ends (How Pi works).

The docs separate the customization mechanisms, and the difference matters for everything below (How Pi works):

Mechanism	What it is	Enforcement
Skills and context files	Instructions the model reads, loaded on demand or at start	None. The model may ignore them.
Prompt templates	Reusable message text expanded from your input	None.
Extensions	TypeScript modules loaded into the Pi process. They register tools, commands, providers, event handlers and UI.	Code. They can block tool calls, and run with the process’s OS permissions.
Packages	A way to distribute extensions, skills, templates and themes through npm or git	Same as their contents.

The homepage says MCP is now built in, together with Codemode (section 10).

These layers answer different questions, and picking the wrong one is the easy mistake. Before writing code, ask what the requirement actually is:

• Instructions or reusable knowledge (how this repo builds, which conventions apply): a context file, a skill, or a prompt template. A skill fits when a workflow “needs more context than a prompt template but does not need a new executable integration point” (Skills).
• Runtime behavior or tool execution (block a call, add a tool, change what the model sees): an extension.
• Integration with other systems: an extension, MCP, or driving Pi from outside through RPC or the SDK (section 9).
• Distribution and upkeep of a set of these: a package. Packages are only a delivery mechanism, and they “can execute extension code and can include skills that instruct the model to run programs”, so reviewing their source is on you (Packages).

3. Tools: what the model can actually do

I’ve used the word “tool” throughout, and the rest of the article leans on it. Permissions, observability, sub-agents and recovery are all, underneath, questions about tool calls. So it’s worth being exact about what a tool is in Pi before going further.

One tool call, step by step

The five parts of the picture have different jobs:

• The model proposes. It sees tool definitions and decides whether to call one. It cannot run anything.
• The agent loop owns execution. It looks the tool up, validates the arguments, runs the hooks, calls execute() and turns the outcome into a message.
• The tool definition is the contract the model reads: name, description and parameter schema.
• The tool’s execute() is ordinary code running in the Pi process, with that process’s OS permissions.
• The tool result goes back into the active branch as a tool-result message, so the next request contains it. That is also the reason big outputs matter: whatever the result holds becomes context.

What ships with Pi

Tool	Responsibility	Default	Output limit (from source)
read	Read text files and supported images	on	2,000 lines or 50 KB, with offset / limit to continue
bash	Run a shell command in the working directory	on	Last 2,000 lines or 50 KB; full output saved to a temp file
edit	Apply exact text replacements to an existing file	on	n/a
write	Create or overwrite a file	on	n/a
grep	Search file contents; respects .gitignore	opt-in	100 matches or 50 KB
find	Find paths by glob pattern; respects .gitignore	opt-in	1,000 results or 50 KB
ls	List a directory, dotfiles included	opt-in	500 entries or 50 KB
powershell	Run PowerShell commands, Windows only	opt-in	like bash

Two more tools come from Pi’s built-in extensions, not from the core tool set. Both are off by default (CLI reference):

Tool	Responsibility
codemode	The model writes JavaScript that calls other tools; only the script’s output comes back (section 10)
tool_search	Finds tools that aren’t declared to the model and declares the matches for the next call

A correction to my own earlier shorthand: section 2 says four tools are on by default and grep, find and ls are opt-in. That’s true but incomplete. There are eight built-in names including a Windows-only shell, and two more tools sit behind extensions.

Core tools, extension tools, and your own

The question “how many tools does Pi have?” has no single answer, because tools reach the model in different ways:

Kind	Defined by	How it reaches the model
Built-in tools	Pi’s core (read, bash, edit, write, grep, find, ls, powershell)	Declared when active; the first four are active by default
Built-in extension tools	Pi’s bundled extensions (codemode, tool_search)	Registered inactive; activated by name or by the MCP extension
MCP tools	An MCP server you configure; named mcp__<server>__<tool>	Per-server exposure: codemode (default, not declared to the model), deferred, direct or hidden (MCP)
Custom extension tools	Your TypeScript extension, through pi.registerTool()	direct by default, activated on registration; other exposures are available
SDK tools	The host application embedding Pi, through the customTools option	Part of the active tool set that tools, noTools and excludeTools control (SDK)

A custom tool is a small piece of code. This is Pi’s own hello.ts example, abridged (source):

const helloTool = defineTool({
  name: "hello",
  label: "Hello",
  description: "A simple greeting tool",
  parameters: Type.Object({ name: Type.String({ description: "Name to greet" }) }),
  async execute(_toolCallId, params, _signal, _onUpdate, _ctx) {
    return {
      content: [{ type: "text", text: `Hello, ${params.name}!` }],
      details: { greeted: params.name },
    };
  },
});

export default function (pi: ExtensionAPI) {
  pi.registerTool(helloTool);
}

Tool, extension, skill, MCP server, package

Section 2 separated the customization mechanisms by what they enforce. Here is the same split by what each one does to the model’s tool surface:

Mechanism	Adds a model-callable operation?	Runs code in the Pi process?
Tool	Yes, it is the operation	Yes, its execute()
Extension	Yes, if it calls registerTool(). It can also add commands, hooks, providers and UI	Yes
Skill	No. The model follows its instructions with tools it already has	No
Prompt template	No. It expands into message text	No
MCP server	Yes, its tools show up as mcp__<server>__<tool>	The server is a separate process or remote service. Pi’s MCP extension is the client
Package	It carries any of the above	Whatever it contains

4. Building the missing pieces

The sequence matters more than any one error. The motivation for the sub-agents was long sessions and large contexts. I didn’t find what I wanted in the form I wanted, so I tried building it. Beyond the effort, what that left me with were questions about delegation: what an orchestrator is responsible for, where a sub-agent’s results and failures go, and who can see them. The rest of this article follows those questions. That is my reading of my own experiment. It’s an interpretation of what happened when I built these pieces, not a claim that Pi lacks delegation capabilities in general.

What the documentation sets up is a separate, checkable matter. Pi names “no sub-agents” as a choice. Its extension guide doesn’t mention sub-agents either, though it does let an extension run other tools with ctx.executeTool(), and those nested calls pass through the same tool_call handlers as model-issued ones (extensions guide). So an orchestrator isn’t something you configure. It’s something you design.

Context is more than a window

Start with what fills the window at all. The system prompt is Pi’s base instructions plus the context files it finds. Tool definitions go out with every request, and the active branch is converted into user, assistant and tool-result messages. Skills load progressively: only each skill’s name, description and path go into the system prompt, and the full SKILL.md is read when the model decides a task matches the description. A skill with disable-model-invocation: true is available only through its explicit /skill:name command. Your own message can carry @ file references, pasted images and !command output (!!command runs a command without sending the output to the model), and extensions can add instructions or transform the context before the request leaves (How Pi works, Skills, Usage, extensions guide).

Long contexts were the reason I wanted sub-agents, so it's worth being exact about what Pi's own mechanisms do. Three things are easy to blur together:

• Compaction manages what the model sees now. It replaces older messages with a summary, so what the summary keeps decides what the agent knows afterwards.
• Persistence keeps the full record on disk, including what compaction hid from the model.
• Branching controls direction: you can go back to an earlier point and try another approach without losing the one you left.

5. When delegation becomes hard to see

The observation is about a gap: a general progress signal versus the ability to inspect real execution. It’s easy to build the first and skip the second. I’m not claiming my extension had or lacked any particular mechanism. The point below is what a delegating system needs, if you want to trust it.

Pi’s building blocks cover part of this. Sessions are stored as JSONL trees recording messages, tool calls and results, and compactions, and JSON and RPC modes stream agent events (How Pi works). The extension API adds finer-grained hooks. Lifecycle events include agent_start, turn_start, message_update and agent_settled, and tool execution has tool_execution_start, tool_execution_update (progress during a call) and tool_execution_end. For nested calls made through ctx.executeTool(), these events carry a parentToolCallId (extensions guide). The SDK exposes session.subscribe() for events of one in-process session (SDK). These are building blocks, and I haven’t verified how they behave across separate child Pi processes. The docs I read describe no dashboard, metrics or tracing system beyond them. Whether a child process appears in that record usefully depends on how you launch it. That’s a design decision you own.

The extension API is where those building blocks get specific. The figure lists the hooks in the order they fire and what each can do: some only observe, some transform what passes through, and a few can block.

Put together, three properties are separate, and an agent can have the first without the others:

• Execution: it can perform actions.
• Observability: you can tell what it is doing and where it is.
• Control: you can intervene, change approach, or stop it.

Delegation without observability creates a system that can act without being easy to understand. That’s a conclusion about the design, not a claim that every multi-agent system works this way.

Control has a documented side too. A person can steer, queue a follow-up or abort (section 2), and a program can do the same over RPC. Those act on a Pi session. How a parent agent would apply them to a child, when it should, and what the child does with them are decisions I would have to design. I’m not claiming Pi can’t do it.

6. When execution stops

That gives two groups, and the difference between them is the useful part: interruptions I could recover from by diagnosing and resuming, and failures that blocked the task. I’m not assigning particular failures (a response error, a tool misuse, context exhaustion) to either group, and I’m not saying any of them is unrecoverable in general. Whether a failure resumes depends on the model, the provider, the configuration and any extensions, and my account doesn’t map one to the other.

This is a different problem from the one in section 5. Observability asks whether you can see what an agent is doing. Recovery asks what happens when what it’s doing breaks. An agent’s ability to execute a task and its ability to recover when execution fails are separate properties. A system can be very good at the first and say little about the second.

I shouldn’t overstate what Pi lacks, because it does have recovery behavior, and the docs describe it:

So the accurate statement isn’t that Pi never recovers. Some failures have a built-in path, and some paths are bounded: three retries by default, and a compaction recovery that ends without a retry if compaction itself fails. The docs I read don’t list which errors count as transient. They also don’t describe built-in handling for a model that keeps using a tool incorrectly, or for a run that ends in a state you want to resume. I don’t know whether any of my failures fell inside or outside the built-in paths. I’m not claiming they were gaps in Pi. They may have been cases where the defaults were exhausted or didn’t apply.

The figure draws those paths and what happens when each one runs out. Solid boxes are documented behavior. The dashed row marks a gap in what I read, not a claim about Pi.

Pi gives you parts of this, and its session tree, which keeps the original entries even after compaction, is a useful record to resume from (How Pi works). I haven’t looked for packages that add retry or safer compaction, so I can’t say whether they exist or how well they work. In an integrated product, more of these decisions may already be made for you. With Pi, defaults are a starting point, and the rest is yours to design, test and maintain. That’s the same trade-off as before, seen from the failure case: freedom to customize an agent doesn’t come with a guarantee that it recovers gracefully.

7. The real permission boundary

The permission-restricting extensions and the Docker attempt from section 4 raised the question of what actually limits an agent. A prompt, a restricted tool and a container are different things, so it helps to separate them.

The loop is conceptual, not a diagram of Pi’s internals:

context → model → tool request → runtime → execution environment → tool result → updated context

Five layers can each be called “permission”:

1. Process permissions. What the OS user running the agent can do. Anything inside the process is bounded by this.
2. Application-level checks. Rules in the agent that inspect a tool call and allow, ask or deny it.
3. Project-directory boundary. Whether the working directory is a fence or only a starting point.
4. Tool capabilities. A structured read can be fenced by path. A shell can run any program, which can open any file.
5. Isolation. Containers, VMs and OS sandboxes restrict the process itself, including its children.

That fits the documentation: by default there’s no application-level fence. But the absence of a prompt doesn’t prove unrestricted access in every setup. An extension can add checks. The tool_call event can mutate or block a call, and a handler that throws blocks it fail-closed (extensions guide). A prompt doesn’t prove comprehensive security either. Claude Code’s docs say its Read and Edit deny rules apply to its built-in file tools, to file commands it recognizes in Bash such as cat, and to redirection targets. They don’t apply to a command that reads files without naming them, such as grep -r pattern ., or to a script that opens files itself. For OS-level enforcement the docs point to its sandbox, and they say bypassPermissions mode should only be used in isolated environments like containers or VMs (permissions). So both sets of docs point to isolation for the real boundary. They differ in the default between you and it. In Claude Code’s Manual mode (the config value default), it asks before most actions that edit files, run shell commands or reach the network (permission modes). A built-in set of read-only commands such as cat and ls runs without a prompt, including on paths outside the working directory, unless permissions.blockReadsOutsideWorkingDirectories is turned on. The docs also say that from v2.1.283, auto mode is the starting mode for interactive terminal and VS Code sessions, with a classifier reviewing actions instead of you. Pi asks for nothing. I compared documentation, not behavior: I haven’t run Claude Code for this article.

Two Pi-specific details are easy to miss:

• Project trust is not a sandbox. It gates what a folder supplies: project settings and MCP servers, extensions, skills, prompt templates and themes under .pi, system-prompt files, and project-configured packages. It “prevents a folder from silently loading executable extensions before you approve it”, and the security page says it “does not limit what tool calls can access or affect”. Extensions run “inside the Pi process with the same operating-system permissions”, so a trusted extension can read prompts, tool calls, files and session history (extensions guide). Context files (AGENTS.md, CLAUDE.md) load without trust (Configuration). Instructions in a repository you cloned can reach the model whether or not you trusted it. Whether a given model would act on a hostile instruction is a separate question I haven’t tested.

• Docker is a tool, not a guarantee. What a container actually isolates depends on what you mount, which credentials you pass in, whether the network is open, and which user it runs as. A container that mounts your home directory and an API key with broad scope has moved the problem, not solved it. This is general container security, not a result from my attempt (Docker security).

In short, three questions get mixed up. Trust asks whether a folder’s own resources may load. Permissions ask what the running process and its tools can technically do. Isolation asks what stays out of reach even if an agent or extension misbehaves. Pi’s docs provide the first, describe the second, and leave the third to you. I haven’t audited Pi’s security beyond reading these pages and one tool’s source.

What Pi’s containerization guide offers

“Bring the container” would be thin advice on its own, and the docs go further. The containerization guide describes four options, and they differ in what the boundary contains:

8. From agent to workflow

Once I looked at using Pi in projects that already used AI-assisted development, a different problem appeared. Capability isn’t workflow. A capable agent doesn’t know how a project builds, which conventions it follows, which tests must pass, or when work counts as done.

The rest of this section is analysis of what fitting an agent into a project costs. It is general reasoning, not a report of something that went wrong in a particular project of mine.

This is where the earlier sections meet. Observability, recovery and the permission boundary are workflow questions at heart: what does the system do, can anyone see it, and what constrains it. An integrated product has made many of those decisions already. With Pi, you make them.

9. No built-in WebUI doesn’t mean no integration options

Pi has no integrated web interface, which I felt as a gap. But a missing UI and missing interfaces are different things. The docs list several ways to drive the same agent (CLI, How Pi works):

Interface	Intended use
Interactive (default)	Terminal UI for a person.
Print (-p)	One prompt, final text to stdout, then exit.
JSON (--mode json)	One-shot run that writes agent events as JSONL.
RPC (--mode rpc)	Long-running process driven by JSONL commands on stdin, events on stdout.
SDK	TypeScript library creating and controlling sessions in-process.

So a web front end isn’t blocked. You could build one over RPC or the SDK. What the interfaces don’t do is the work around them: rendering the UI, handling streamed output, keeping session state, deciding what happens on errors (section 6), and managing the agent’s lifecycle. The SDK page even names a subtlety you’d have to handle: agent_end marks the end of one run, while agent_settled signals that Pi won’t continue automatically. I haven’t built such a front end, so this describes the documented surface and not my experience.

The details are where the work hides (RPC). The figure shows the shape of one prompt over the RPC interface, and the part a naive client gets wrong.

10. Code Mode: a design direction I haven’t tried

I found Pi’s Code Mode in the docs. I haven’t used it on a real task, so this section describes the documented design and nothing about results.

I’d like to try it on a real task before judging it. Until then it stays a hypothesis.

11. More tools, a better agent?

My first reaction to Pi’s thin environment (section 1) was to count what was missing. The tool system makes that reaction worth examining, because it’s tempting to turn “fewer built-in tools” into “less capable”. I don’t think tool count settles anything, and the comparison below is meant to show why.

What the three harnesses ship

	Pi	Claude Code	Codex
Built-in tool surface	8 core tools (4 on by default), plus 2 off-by-default extension tools	The tools reference lists 46 entries. Several are conditional: task tools depend on the model, Grep and Glob are left out by default on macOS, Linux and WSL, and one entry is marked removed	No documented list or count. The source has handlers for shell execution (exec_command, write_stdin), apply_patch, update_plan, view_image, request_user_input, request_permissions, MCP resource tools, tool_search, multi-agent tools and hosted web search. I didn’t verify which are on for a given model or config
File editing	edit (exact replacement), write	Edit, Write, NotebookEdit	apply_patch
Search	bash, or opt-in grep / find / ls	Grep / Glob on Windows. Elsewhere, Claude searches with find and grep through Bash by default	Through the shell tool. I found no dedicated search handler
Planning, sub-agents	Not built in; the homepage says “No sub-agents”, “No plan mode”	Agent, EnterPlanMode, AskUserQuestion, task tools, worktree tools and more	update_plan, request_user_input, multi-agent tools. Docs describe subagents as a customization layer
Adding tools	registerTool() in an extension, SDK customTools, MCP	MCP (“To add custom tools, connect an MCP server”). A skill “runs through the existing Skill tool rather than adding a new tool entry”. Hooks and permission rules constrain tools	MCP, with enabled_tools / disabled_tools for MCP servers. Skills are instructions; plugins package and distribute them
Permissions and sandbox	No approval prompts and no sandbox by default; the docs tell you to bring a container	Allow and deny rules per tool name, permission modes, and a per-tool flag for whether a prompt is required	An OS-enforced sandbox (Seatbelt, bwrap plus seccomp) plus approval policies. In version-controlled folders the default is workspace-write with on-request approval
Controls on context cost	--tools allowlists, exposure, tool_search, codemode	ToolSearch defers MCP tool definitions by default; alwaysLoad opts a server out	enabled_tools / disabled_tools; a tool_search tool exists in the source

The argument: a bigger toolset isn’t automatically a better agent

My claim is narrower than “fewer is better”. A larger toolset does not by itself make an agent more capable, reliable or useful, and a smaller one doesn’t by itself make it safer or simpler to live with. Six angles follow, each marked for what kind of claim it is.

1. Simplicity versus capability. Opinion A few general tools can cover the fundamental operations: read, write, edit and run a command. bash alone can already do what grep, find and ls do, which is why those three are opt-in in Pi, and Claude Code’s docs say that on macOS, Linux and WSL it too leaves Grep and Glob out by default and searches through Bash. Overlap is where a bigger set starts to cost: two tools that do nearly the same thing give the model a choice to make and give you two behaviors to understand. But a small set has overlap too (edit and write both change files, and bash can do either), so small is not the same as non-overlapping.

2. Tool selection and reasoning. Opinion The intuition is that every extra tool is another option the model must weigh, which could make selection less predictable. I haven’t measured that, and neither the Pi nor the Claude Code docs I read make a claim about selection accuracy, so I treat it as a hypothesis. What the docs do show is that both products built mechanisms to avoid declaring everything upfront (the figure), which suggests their authors take the cost of a large declared set seriously. That’s an inference about intent, not a stated reason.

3. Extensibility versus built-in completeness. Opinion A minimal core makes fewer assumptions and is easier to read end to end. The matching cost is the one this whole article is about: whatever the core leaves out, someone must build, test and maintain. Pi’s extension API is generous, but a custom tool is code you own, written against an API that has changed (section 12 notes the package rename). An integrated harness has done that work once, for everyone.

4. Control versus convenience. Opinion A small default set is a clear base to customize: you can read what the model is offered, change it, and hook every call. A polished harness gives you something working on the first day. Both are real goods. Which one wins depends on whether you’ll ever use the control, and I’d be dishonest to claim I always did.

5. Context and implementation cost. Documented Tool definitions, schemas and instructions are context. Claude Code’s docs say “each upfront tool consumes context that would otherwise be available for your conversation”, that every skill in the listing “adds to your context on every turn”, and that tool search keeps MCP context low “by deferring tool definitions until Claude needs them”. Pi caps the tool declarations in codemode’s description at 3,000 estimated tokens by default. Outputs matter too: Pi’s built-ins truncate at 2,000 lines or 50 KB, and Claude Code persists oversized MCP results to disk past 50,000 characters. Opinion So the cost is real, but it depends on what is declared. Ten small tools may cost less than one with a huge schema, and a deferred tool costs close to nothing until it’s needed. The claim “every extra tool hurts” doesn’t follow.

6. Reliability and responsibility. Opinion A smaller toolset doesn’t make an agent safe or reliable. Pi’s four default tools include bash, which can do almost anything the user can, and its security docs say plainly that it doesn’t ask before each call. Codex ships a sandbox and approval policies, and Claude Code ships per-tool permission rules, and neither depends on how many tools exist. What decides reliability is the quality of each tool’s implementation, validation, error reporting, and the boundary around execution. A tool with a vague description or silent failures hurts more than a missing tool.

Where Pi’s minimalism helps, and where it costs

Where it helps	Where it costs
A short, readable surface: eight names, four by default	Anything beyond file work and bash is yours to build or install
You choose what the model sees (--tools, exposure)	You must know that choice exists, and make it
One hook point sees every call, nested ones included	The hook is a policy surface, not a sandbox; the boundary is yours to build (section 7)
Few assumptions baked in, so fewer surprises from the harness	Common workflows (plans, sub-agents, approvals) start as a blank page
Easy to embed through RPC or the SDK	Embedding makes you the owner of the glue (section 9)

12. Freedom, convenience, and who owns the system

What do these experiments add up to? Extensibility is the point of Pi: programmable behavior, a single hook where every tool call can be inspected or refused, event streams you can build on, and a core small enough to understand. Each of those has a matching cost, and the cost is the same each time. The decision moved to me.

What Pi gives you	What it asks of you
Shape more of the system	Decide what’s in it, and maintain it
Custom behavior fitted to your needs	Test it, and keep it working as Pi changes. Packages moved npm scopes once: @mariozechner/pi-coding-agent dates from November 2025, @earendil-works/pi-coding-agent from May 2026, per the npm registry, which now marks the old name as deprecated in favour of the new one.
See and change architectural decisions	Make them well: permissions, isolation, observability, recovery from failure
No bundled policy to fight	Supply your own, or work without one

The tool system is the clearest example. Pi gives you a small set of primitives and a place to add your own, and section 11 argues that this is a bet and not a deficit. Integrated products aren’t the opposite of extensible. Claude Code, for example, has hooks, skills, sub-agents, plugins and MCP, and Pi isn’t without conveniences. The difference is how much is decided for you by default, and who maintains it.

13. When should you use Pi?

Working with Pi made me more aware of a trade-off that’s easy to overlook: freedom transfers responsibility. The more control you have over a system, the more decisions you need to make to turn that control into a reliable working experience. Pi’s own documentation says as much about permissions: it tells you to bring the container, and documents four ways to do it.

So the question isn’t whether Pi is better than other coding agents. I haven’t tested that, and this article makes no claim about it. The question is whether the freedom Pi offers is worth the additional work you’re willing to take on. I opened with a powerful model in a thin environment. The thin environment is the offer, and the work of filling it in is the price.

Freedom gives you the ability to build the system you want. Convenience lets you spend less time building the system in the first place.

References

Pi: official docs and source

• pi.dev, Sessions, Skills, Packages, Extensions, SDK, How Pi works, Security, Configuration, Settings, Compaction, CLI, Code Mode, Usage, RPC, Containerization, MCP, Quickstart
• earendil-works/pi: extensions.md, src/core/tools (including read.ts), agent-loop.ts, types.ts, hello.ts, tool-override.ts, path-utils.ts, utils/paths.ts
• npm registry metadata (npm view) for @earendil-works/pi-coding-agent and the deprecated @mariozechner/pi-coding-agent, checked October 20, 2026

Pi: authors’ posts

• Mario Zechner, What I learned building an opinionated and minimal coding agent, November 2025
• Earendil, You Said No MCP!, September 29, 2026

Comparison and background

• Claude Code, Tools reference, MCP (including tool search), Skills, Configure permissions and Permission modes
• OpenAI Codex, Customization, MCP, Agent approvals and security, and the open-source tool handlers in openai/codex (commit e18a20d)
• Docker, Docker security