> ## Documentation Index
> Fetch the complete documentation index at: https://docs.asymptotelabs.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Oh My Pi
> Asymptote support details for Oh My Pi (omp) endpoint telemetry
## Runtime overview
Asymptote supports [Oh My Pi](https://github.com/can1357/oh-my-pi) through a managed local extension.
Oh My Pi is a fork of [pi-mono](https://github.com/badlogic/pi-mono) that ships as the `omp` binary, so it fits the same integration shape as [Pi](/runtimes/pi): no hooks configuration file to merge a managed hook block into, and no OpenTelemetry support to point at the local collector. Its observation surface is the TypeScript extension API, so one Asymptote-owned extension file forwards runtime events to `beacon-hooks`.
```bash theme={null}
beacon endpoint hooks install --harness omp
```
Oh My Pi and Pi are separately installed products, and Asymptote records them under separate harness names. A machine running both produces two distinct streams; nothing is merged. If you are looking for upstream Pi, see [Pi](/runtimes/pi).
## Prerequisites
Before enabling Oh My Pi telemetry, make sure:
* Oh My Pi is installed and available as the `omp` executable, or has a local state directory at `~/.omp/agent`.
* `beacon endpoint install` has run so shared endpoint config and runtime log paths exist.
* Oh My Pi is restarted after install or removal so new sessions load the updated extension.
## Collection path
Asymptote's managed extension is a single TypeScript file in one of Oh My Pi's two auto-discovered extension directories:
| Level | Extension path |
| ------- | ----------------------------------- |
| User | `~/.omp/agent/extensions/beacon.ts` |
| Project | `./.omp/extensions/beacon.ts` |
User level is the default, and `beacon endpoint discover` reports on the user path only.
The two paths resolve asymmetrically, which matters if you set either of Oh My Pi's directory variables:
| Variable | Effect on the install path |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `PI_CODING_AGENT_DIR` | Replaces the user agent directory outright, so the extension goes to `$PI_CODING_AGENT_DIR/extensions/beacon.ts`. Oh My Pi sets this on its own process when a named profile is active, so installing from inside a profiled session lands in `~/.omp/profiles//agent/extensions/` |
| `PI_CONFIG_DIR` | Renames the `.omp` directory under your home directory only. The project path stays `./.omp/extensions/` |
Asymptote identifies its own extension by the marker `beacon-managed-omp-extension:v1`, which is distinct from Pi's. The version suffix is part of the contract with the extension source: it is what lets a repair recognize a stale file instead of leaving it in place. A `beacon.ts` without the marker belongs to somebody else, so install will not overwrite it and discovery does not report it as Asymptote telemetry.
Oh My Pi has no OpenTelemetry export for Asymptote to configure, so there is no OTLP path for this runtime.
## Discovery and status
Asymptote detects Oh My Pi through the `omp` executable, and treats the resolved agent directory as an additional signal. Oh My Pi installed through bun, a version manager, or its own installer is often missing from the `PATH` the endpoint process inherited while its state directory is still present. The Pi, OpenCode, Cursor, and Hermes probes use the same fallback.
```bash title="Show Oh My Pi discovery state" theme={null}
beacon endpoint discover --all --json
```
Oh My Pi reports as the `omp` harness with capability `plugin`:
| Telemetry status | Meaning |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------- |
| `missing` | No extension file at the user-level managed path |
| `disabled` | A `beacon.ts` exists but carries no Asymptote Oh My Pi marker, so it is somebody else's extension sharing the filename |
| `enabled` | Asymptote's managed extension is in place |
A file carrying Pi's marker at this path is not an Oh My Pi install. The two runtimes read different directories, so it should not arise, but the markers are distinct so the answer does not depend on that staying true.
## Install or configuration support
```bash theme={null}
beacon endpoint hooks install --harness omp # user level (default)
beacon endpoint hooks install --harness omp --level project
beacon endpoint hooks status --harness omp
beacon endpoint hooks uninstall --harness omp
```
`oh-my-pi` and `ohmypi` are accepted as `--harness` values alongside `omp`.
Install writes one file and refuses to touch a `beacon.ts` it did not write, so an extension of your own that happens to share the filename is left alone and the install fails loudly rather than replacing it. Uninstall removes only a file carrying Oh My Pi's own marker.
Unlike Pi, a project-level install needs no trust prompt: Oh My Pi loads `.omp` project inputs unconditionally, and its extension API's `isProjectTrusted()` always returns true. The difference between the two levels is scope, not interaction — a project install covers one checkout, while a user install follows the operator across checkouts.
`status` reports `installed=false` when the extension exists but points at a hook binary that is no longer there, which happens after a Beacon uninstall, a partly applied update, or a home directory restored onto a different machine. In each case Oh My Pi loads an extension that spawns nothing.
## Telemetry coverage
| Area | Support |
| ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Runtime discovery | Supported through executable and agent-directory detection, managed extension path, and telemetry status |
| Harness attribution | Supported. `omp`, `omp_cli`, `omp-cli`, `oh-my-pi`, `oh_my_pi`, `ohmypi`, and `omp.sh` all normalize to `omp` |
| Extension install, status, uninstall, and repair | Supported |
| Session lifecycle | Supported. `session.started` and `session.ended` |
| Prompts | Supported. `prompt.submitted`, with whether the input was typed, delivered over RPC, or injected by another extension |
| Tool use | Supported. `tool.invoked` before execution, then `tool.completed` or `tool.failed`, joined by `gen_ai.tool.call.id` |
| **Approval decisions** | **Supported.** `approval.requested`, `approval.allowed`, and `approval.denied` from real operator prompts, carrying the command or file being decided on, the approval mode the session was running under, and the tool call id of the execution they decided. This is the capability Oh My Pi has that upstream Pi does not |
| Commands | Supported. `command.executed` for the agent's `bash` tool, for commands you run with the `!` prefix, and for code you run with the `$` Python prefix — the last two marked as operator-initiated |
| File activity | Supported. `file.read`, `file.created`, and `file.modified`, with the unified patch on an edit |
| MCP activity | Supported. `mcp.tool_invoked` with the server and tool resolved from Oh My Pi's `mcp___` naming |
| Agent reasoning | Supported. `agent.reasoning` from an assistant message's thinking parts, in the OTel GenAI reasoning-part shape |
| Token usage and cost | Supported. `token.usage` normalized into `gen_ai.usage`, including cache and reasoning tokens and runtime-reported cost |
| Local JSONL and dashboard | Supported |
| MDM deployment | Supported for the endpoint agent. The extension installs separately in the logged-in user's context |
### Approval telemetry
Asymptote never synthesizes an approval from a tool call. A `tool_call` handler that blocks is an extension deciding, not an operator being asked, and recording that as an approval would be indistinguishable from an answer a human gave — which is why [Pi](/runtimes/pi) and [Cline](/runtimes/cline) carry no approval telemetry at all.
Oh My Pi reports the prompt and the answer as their own events, so its approval events are real. Each one carries:
* The operator's decision, and the runtime's own reason when it gave one.
* The command or file path being decided on. Oh My Pi's approval events carry the tool name but none of its arguments, so the managed extension remembers each `tool_call`'s input by the runtime's own call id and attaches it to the approval for that call. Without this the approval would say "the operator denied `bash`" rather than "the operator denied `rm -rf /var/data`", and every approval rule Asymptote ships matches on the command or path rather than on a tool name.
* `gen_ai.tool.call.id`, joining the decision to the `tool.invoked` it decided on.
* The session's approval mode in `raw.omp_approval_mode`: `always-ask`, `write`, or `yolo`. A `yolo` session had the prompts turned off, which is the difference between a decision someone made and a decision nobody was asked to make.
A resolved approval whose outcome Asymptote cannot read is recorded as a denial. The safe reading of "no evidence the operator said yes" is not "the operator said yes". An approval for a call the extension never saw proposed still records the decision, the tool name, and the call id, without inventing a command block for it.
Detections in `rules/approval-abuse/` fire on Oh My Pi activity, unlike on Pi. A denied `rm -rf` followed by its execution raises `approval-denied-command-executed-anyway`; a `yolo`-mode allow of a destructive command raises `high-risk-approval-allowed-without-reason`.
## Data handling
Oh My Pi content is handled like every other runtime. Prompts, tool arguments, commands, Python source, paths, diffs, and reasoning text are retained in local or customer-controlled logs, with local secret redaction and per-string limits applied before writing, and a hash and byte count on each content-bearing event. Events over the 64 KiB limit drop raw and retained content, preserve stable metadata, and set `field_truncated`.
The extension itself sends nothing over the network. It spawns the local `beacon-hooks` binary with a fixed argv and writes the event to its stdin. A send that has not completed in two seconds is abandoned so Beacon cannot stall Oh My Pi's agent loop, and a failure to spawn costs the event rather than the run. Every handler returns nothing, so Oh My Pi never reads a directive back from Asymptote — the extension cannot block a tool call, revise its arguments, or answer a question that was put to the operator.
## Known gaps
* **No enforcement.** As with every other runtime, enforcement stays behind the optional, off-by-default policy provider seam (`BEACON_POLICY_PROVIDER`), which is not wired to Oh My Pi. Its blocking `tool_call` handler and its approval events make it a viable target for that seam later.
* **Streaming events are not collected.** The extension subscribes to ten of Oh My Pi's event types and ignores the rest, which are provider-request internals, streaming message updates, compaction and retry signals, and TUI plumbing. Assistant output is recorded once when a message finalizes rather than token by token, so Beacon stays out of the streaming path.
* **MCP notifications are not collected.** `mcp_notification` fires for every JSON-RPC notification a connected server sends, most of them routine tools and resources list refreshes. It describes MCP transport plumbing rather than an action the agent took. MCP tool calls the agent makes *are* collected.
* **Named profiles need the environment variable.** Asymptote installs into the agent directory `PI_CODING_AGENT_DIR` names, or the default one when it is unset. It does not enumerate `~/.omp/profiles/`, so instrumenting a named profile means running the install with that variable set — which is what Oh My Pi itself does inside a profiled session.
* **Session switches are not distinguished.** Oh My Pi's `session_start` carries no reason, and its `session_switch`, `session_branch`, and `session_tree` events are not subscribed to, so a resumed or forked session is not marked as such.
## Deployment notes
The extension is loaded when Oh My Pi starts, so an install taken while it is running takes effect on the next launch.
Confirm discovery sees the runtime, then generate one Oh My Pi event and check the log:
```bash theme={null}
/opt/beacon/bin/beacon endpoint discover --all --json
/opt/beacon/bin/beacon endpoint hooks status --harness omp
/opt/beacon/bin/beacon endpoint doctor --system
grep '"name":"omp"' ~/.beacon/endpoint/logs/runtime.jsonl | tail -3
```
## Related
The upstream runtime Oh My Pi forked, supported separately.
Return to the runtime support overview.