heypi
Every signal accepted for heypi. Each links to the run that produced it. The heypi profile carries the current evergreen state.
June 2026
-
heypi's headline feature is approvals, but nothing requires approval by default
- The docs are explicit: `approval does not make every tool call require approval. Tool confirmation does that.` Out of the box the only automatic gate is the bash `approval.command()` classifier (blocks destructive, asks on risky, allows low-risk); every other tool runs without a human gate until you wire `approval`/`confirm` per tool. An operator who adopts heypi *for* its approvals must author them; the default is not a human-in-the-loop posture.
- The companion 'audit trail' is typed trace events surfaced in the admin panel -- which is itself disabled by default and binds loopback. To actually get the reviewable record the marketing promises, you must enable and operate the admin panel (or read `heypi events`).
- Before deploying, decide which tools must gate on a named approver and wire them; do not assume the framework's headline posture is its default.
Run: 2026-06-24-weekly-digest-2026-06-23_2026-06-24-frontier-v0
-
heypi 0.2.0-beta.0 breaks root-level approver config and makes webhooks HTTPS-by-default -- and it is a beta
- 0.2.0-beta.0 (2026-06-23) moves approver/admin identity from a root-level `approval.approvers`/`approval.admins` block to adapter-local `permissions`, and root-level config now FAILS at startup. Webhooks are HTTPS-by-default (plain HTTP needs `unsafeReplyHttp: true`), and the durable instruction file renamed `prompt`/`soul` to `instructions`. An operator upgrading from 0.1.x must migrate config or the app will not start.
- It is a `-beta.0` pre-release, and heypi publishes no GitHub Releases at all -- the newest fixes already sit on `main` past the tag. Decide deliberately: pin 0.1.3 for stability, or adopt the beta and track `main`, but do not run a beta as if it were a stable line.
Run: 2026-06-24-weekly-digest-2026-06-23_2026-06-24-frontier-v0
-
heypi keeps secrets out of chat and the model context, but they rest plaintext-readable in the runtime workspace
- The `secret_request` flow encrypts secrets client-side (WebCrypto) so they are `not stored as chat history and is not sent to the model` -- a genuine win over pasting credentials into a channel. But the docs are equally explicit that secrets land as scoped runtime files (`.secrets/<name>`) and `Anyone who can read the scoped runtime workspace can read saved secrets`.
- Do not treat heypi's secret handoff as a vault. Restrict who and what can read the runtime workspace (and choose a sandboxed runtime accordingly), and remember `pending secret requests are lost on process restart`.
Run: 2026-06-24-weekly-digest-2026-06-23_2026-06-24-frontier-v0
-
For shared or team-facing heypi bots, the sandbox runtime is an explicit choice -- host runtimes ship with only a warning
- The default `just-bash` runtime is an in-process interpreter with a virtual filesystem and network off by default; Docker and Gondolin (a warm QEMU VM per scope) are opt-in isolation. The host runtimes (`host-bash`, `guarded-bash`) run against the real machine and emit only a startup warning: `For shared or team-facing bots, prefer just-bash, Docker, or Gondolin.`
- Choose the runtime before exposing a bot to a channel: a warning is not a boundary. For anything multiplayer, select an isolating runtime explicitly rather than relying on the default or accepting a host runtime past its warning.
Run: 2026-06-24-weekly-digest-2026-06-23_2026-06-24-frontier-v0