senpi

⚠️ Experimental. senpi is an opinionated, in-flight fork of badlogic/pi-mono. It powers Dori under the hood and reflects what one specific AI assistant needs from a coding-agent runtime. Use it; don't bet a production pipeline on it.

senpi is a senpai-name pun and a more sane pi with extra batteries included — a TypeScript monorepo that rebrands pi-mono's coding agent as senpi and ships a curated set of builtin extensions and core tweaks on top of upstream.

Upstream: pi-mono by @mariozechner — tools for building AI agents and managing LLM deployments.

Inspired by OMO, built as Dori's coding-agent runtime

senpi was born from two influences:

• Strong influence from OMO (oh-my-openagent). OMO is the heavyweight opencode harness with discipline agents (Sisyphus, Hephaestus, Prometheus), IntentGate, hash-anchored edits, Team Mode, skill-embedded MCPs, Ralph Loop, todo enforcers, and a lot more. senpi reuses many of OMO's signature ideas (intent gate, dynamic prompt, per-model presets, parallel-tool routing, todo continuation) but keeps the surface as light as possible so it can stay close to upstream pi-mono. Think of senpi as a light version of OMO that runs as a single pi CLI binary instead of an opencode plugin.
• senpi is the coding-agent runtime for Dori. Dori is Sisyphus Labs' AI assistant — see the Dori callout in OMO's README for context. senpi is usable standalone, but the design decisions (intent gate phrasing, builtin extension set, prompt presets per model family, branding) are tuned for what Dori needs when it executes code work.

Core source modifications are minimised and tracked in changes.md files alongside every modified subdirectory so upstream merge commits stay reviewable.

Coming from OMO? Recommended extension setup

If you're migrating from OMO (oh-my-openagent), here is the practical map from "what I used in OMO" to "what to install in senpi". A lot of OMO's signature work is already wired into senpi as a builtin (nothing to install); the rest lives in the code-yeongyu/pi-* GitHub repos and is one senpi install away.

senpi is intentionally lighter than OMO — single CLI binary, not an opencode plugin. Some OMO concepts (Discipline Agents, Team Mode, Skills, Hashline, Ralph Loop, /init-deep) have no 1:1 senpi counterpart and are flagged at the bottom of this section. If you need those, keep using OMO.

Already builtin in senpi — nothing to install

Choose extensions for your OMO setup

Senpi builtins, standalone pi-* extensions, and the OMO Senpi plugin overlap. Do not install every standalone package when the capability is already provided by Senpi or the plugin.

For standalone Senpi without the OMO plugin, install only the non-builtin capabilities you need:

senpi install git:github.com/code-yeongyu/pi-lsp-client            # 🛠️  LSP: rename / goto / refs / diagnostics + /lsp inspector
senpi install git:github.com/code-yeongyu/pi-ast-grep              # 🛠️  AST-Grep across 25 languages (auto-downloads sg)
senpi install git:github.com/code-yeongyu/pi-comment-checker       # 💬  Comment Checker — the standalone pi port of OMO's hook

# Optional — only if you used the matching OMO surface:
senpi install git:github.com/code-yeongyu/pi-cua-integration                 # 🖥️  Computer-use bindings (desktop / browser)
senpi install git:github.com/code-yeongyu/pi-anthropic-computer-use          #     Claude-native computer use
senpi install git:github.com/code-yeongyu/pi-anthropic-code-execution        #     Claude-native code execution
senpi install git:github.com/code-yeongyu/pi-google-code-execution           #     Google-native code execution
senpi install git:github.com/code-yeongyu/pi-openai-code-interpreter         #     OpenAI Code Interpreter
senpi install git:github.com/code-yeongyu/pi-anthropic-text-editor           #     Claude-native text editor tool
senpi install git:github.com/code-yeongyu/pi-anthropic-tool-search           #     Claude-native tool search
senpi install git:github.com/code-yeongyu/pi-anthropic-web-fetch             #     Claude-native web fetch
senpi install git:github.com/code-yeongyu/pi-google-google-search            #     Google Search grounding
senpi install git:github.com/code-yeongyu/pi-google-url-context              #     Google URL grounding
senpi install git:github.com/code-yeongyu/pi-openai-api-parallel-tool-calls  #     OpenAI parallel_tool_calls payload support

See Senpi Packages for the full install / update / remove flow.

Allow all permissions (OMO-style)

OMO runs with all tool permissions pre-approved. To replicate that behavior in senpi, add a wildcard allow rule to your global settings:

mkdir -p ~/.senpi/agent
cat > ~/.senpi/agent/settings.json << 'EOF'
{
  "permission": {
    "*": "allow"
  }
}
EOF

This tells the permission system to auto-approve every tool call without prompting. The "*" key matches all permission names, and "allow" grants them unconditionally. You can also set this per-project by placing the same settings.json in .senpi/settings.json at the project root.

Note: This disables all interactive permission prompts. Only do this if you trust the model and the workspace you are running in.

No direct senpi counterpart

These are part of OMO's opencode harness shape and are intentionally not in senpi:

• Discipline Agents (Sisyphus / Hephaestus / Oracle / Librarian / Explore / Multimodal Looker) and the ultrawork / ulw one-word orchestration entrypoint.
• Team Mode — lead + up to 8 parallel members, tmux visualization, team_* tool family, hyperplan / security-research skills riding on top.
• Hashline / hash-anchored edit tool — senpi stays with pi's standard edit / multiedit / apply_patch. pi-comment-checker covers the post-edit validation slot OMO uses Hashline for, just without LINE#ID content-hash identifiers.
• Skill system and skill-embedded MCPs — skills as a first-class concept (SKILL.md, scoped per-skill MCP servers) do not exist in senpi.
• Prometheus interview-mode planner and the Ralph Loop / /ulw-loop self-referential loop.
• /init-deep — there is no in-tree generator. Generate the hierarchical AGENTS.md tree manually (or with a normal agent prompt); the builtin nested-agents-md extension will read the resulting files.
• Built-in doctor command, Claude Code hook/command/skill/plugin compatibility layer, and the agent category router (visual-engineering / deep / quick / ultrabrain).

Want more? Try the pi-extensions ecosystem

senpi ships a fixed set of builtin extensions and stops there. The code-yeongyu/pi-* GitHub repos contain the full extension ecosystem: some packages are vendored into senpi as builtins, while the rest can be installed on top when you want extra capabilities such as LSP or AST-grep.

Installable extensions

These code-yeongyu/pi-* packages are intended to be installed as standalone senpi/pi extensions:

Install any of them with:

senpi install git:github.com/code-yeongyu/pi-ast-grep
senpi install git:github.com/code-yeongyu/pi-lsp-client
# ...substitute any of the package names from the table above.

See Senpi Packages for the install / update / remove flow.

pi-extension packages already shipped as senpi builtins

You do not need to install these packages for normal senpi use; their functionality is already included in the binary. This table is intentionally limited to packages that map to the currently registered builtinExtensions list:

Other builtins such as permission-system, prompt-preset, anthropic-bash, service-tier, tool-pair-guard, compaction, history-search, and session-observer are senpi-owned builtin extensions without installable sibling packages.

Why "senpi"

senpi is a small joke on senpai, but it is also literal project positioning: this fork aims to be a more sane pi with practical additions that make everyday agent work smoother without abandoning upstream's core design.

All additions follow pi's extension-first philosophy. Core source modifications are minimized and documented in changes.md files to keep upstream merge commits reviewable.

What this fork adds

senpi inherits pi's extension-first design — the core stays minimal, every feature lands as a builtin extension. The bet is that an opinionated set of features is wanted often enough to be in the binary; anything you don't want is still one settings flag away from being off (disabledBuiltinExtensions in settings.json).

Verified against git diff upstream/main..HEAD and every changes.md file in the repo.

New core subsystems

Owned builtin extensions

In-tree, tightly coupled to senpi internals. Loaded in this exact registration order:

The builtin directories above are new vs upstream pi-mono — none exist in badlogic/pi-mono. Vendored versions are pinned in external-versions.json and synced from the sibling pi-extensions checkout with sync-builtin-extensions.mjs.

Standalone extension repositories

These are maintained as public code-yeongyu/pi-* repositories and can be installed through settings.json packages or senpi install git:github.com/code-yeongyu/<repo>.

Global default extensions

Not loaded as builtins; written once into ~/.senpi/agent/extensions/ on first run so you can edit or remove them locally.

Modified upstream packages

Other branding / runtime changes

Fork Strategy

This fork rebases periodically on upstream/main. To minimize merge conflicts:

1. Extension-first: All features use pi's extension system as builtin extensions.
2. Document core changes: Every upstream file modification has a corresponding changes.md in the affected subdirectory, documenting what changed, why, and expected conflict zones.
3. Remotes: origin = code-yeongyu/senpi, upstream = badlogic/pi-mono.

Modified upstream files (high-impact, see per-directory changes.md for the rest):

Share your OSS coding agent sessions

If you use pi or other coding agents for open source work, please share your sessions.

Public OSS session data helps improve coding agents with real-world tasks, tool use, failures, and fixes instead of toy benchmarks.

For the full explanation, see this post on X.

To publish sessions, use badlogic/pi-share-hf. Read its README.md for setup instructions. All you need is a Hugging Face account, the Hugging Face CLI, and pi-share-hf.

You can also watch this video, where I show how I publish my pi-mono sessions.

I regularly publish my own pi-mono work sessions here:

• badlogicgames/pi-mono on Hugging Face

All Packages

For Slack/chat automation and workflows see earendil-works/pi-chat.

Permissions & Containerization

senpi does not include a built-in container boundary for restricting filesystem, process, network, or credential access. By default, it runs with the permissions of the user and process that launched it.

If you need stronger boundaries, containerize senpi. See packages/coding-agent/docs/containerization.md for three patterns:

• OpenShell: run the whole senpi process in a policy-controlled container.
• Gondolin extension: keep senpi and provider auth on the host while routing built-in tools and ! commands into a local Linux micro-VM.
• Plain Docker: run the whole senpi process in a local container for simple isolation.

Contributing

See CONTRIBUTING.md for contribution guidelines and AGENTS.md for project-specific rules (for both humans and agents).

Development

npm install --ignore-scripts  # Install all dependencies without running lifecycle scripts
npm run build        # Build all packages
npm run check        # Lint, format, and type check
npm test             # Run tests (skips LLM-dependent tests without API keys)
./pi-test.sh         # Live-API integration suite (env-gated; requires API keys)
npm run publish      # Publish npm workspaces, including @code-yeongyu/senpi

Supply-chain hardening

We treat npm dependency changes as reviewed code changes.

• Direct external dependencies are pinned to exact versions. Internal workspace packages remain version-ranged.
• .npmrc sets save-exact=true and min-release-age=2 to avoid same-day dependency releases during npm resolution.
• package-lock.json is the dependency ground truth. Pre-commit blocks accidental lockfile commits unless PI_ALLOW_LOCKFILE_CHANGE=1 is set.
• npm run check verifies pinned direct deps, native TypeScript import compatibility, and the generated coding-agent publish dependency manifest.
• packages/coding-agent/publish-deps.lock.json is generated from the root lockfile for publish staging but is never shipped; publishing an npm-shrinkwrap.json beside bundled dependencies breaks npm installs.
• Release smoke tests use npm run release:local to build, pack, and create isolated npm and Bun installs outside the repo before tagging a release.
• Local release installs, documented npm installs, and senpi update senpi use --ignore-scripts where supported.
• CI installs with npm ci --ignore-scripts, and a scheduled GitHub workflow runs npm audit --omit=dev plus npm audit signatures --omit=dev.
• Shrinkwrap generation has an explicit allowlist for dependency lifecycle scripts; new lifecycle-script deps fail checks until reviewed.

Contributing

See CONTRIBUTING.md for contribution guidelines and AGENTS.md for project-specific rules (for both humans and agents).

License

MIT

Ganbare Ganbare Senpi

Hora, senpi senpi, senpi te kudasai! Ganbare ganbare senpi, gan ganbare ganbare senpi ora!

A tiny, completely unserious love letter to the Ganbare Ganbare Senpai meme that the project's name secretly bows to. Every time the rebase is clean and the tests are green, somewhere a kouhai whispers:

• C'mon senpi, c'mon! Ship the PR.
• Notice me, senpi. ...the diagnostics noticed first.
• Try harder, senpi! (she did look. and the build did pass.)
• You can do it, senpi! One more agent, one more tool, one more clean rebase.
• Ganbare, ganbare, senpi! 頑張れ頑張れ先輩! Do your best, do your best, senpai!

Yes, the entire project name is a senpai pun. Type strictly, run the tests, write a changes.md, keep the merge surface tiny — and gan ganbare ganbare senpi ora!

Shoutout to plugsuits: senpi's compaction system takes inspiration from its design.