Oh My Pi with UHP: adapter pins and compatibility checks

Keep tool-call parsing separate from tool success

Oh My Pi’s current v18.6.0 release fixes an instructive failure: malformed DeepSeek DSML tool-call text could remain in history while the agent stopped as if the model had finished. The release describes cleaning the broken markup and requesting a corrected call, bounded to two retries. That is upstream behavior at 18.6.0; the CE adapter below still defaults to 18.1.13.

For adapter evaluation, inspect the tool evidence rather than accepting a transcript that merely looks like a tool call:

Evidence	Interpretation
Model emits a proposed call	Intent was generated; execution is not yet established
Parser yields a recognized tool name and arguments	Dispatch can be checked against policy
Tool result plus artifact/state evidence	Execution and its outcome can be assessed
Malformed markup or unknown tool	Keep a distinct parse/dispatch failure; do not promote it to success

Choose a fixture that requires one real file read or edit, then verify both event arguments and the resulting state. For MCP, the historical xd://mcp__... dispatch examples below show why generic tool-name counting can undercount actual adapter calls. Conversely, counting strings in generated prose can overcount them.

The tool-surface guide explains how the product registry, runtime-declared tools and policy must agree. Preserve raw error/parse evidence and the installed binary version in any comparison. The old 705/705 matrix remains its own source result; a newer parser fix is not a fresh rerun of that matrix.

Separate the release from the tested adapter

The latest upstream release observed on 4 October 2026 is Oh My Pi v18.6.0. HarnessRouter v0.29.0 still defaults HR_OMP_VERSION to 18.1.13 in its installation entrypoint. An override changes the installed software; it does not rerun compatibility tests.

The earlier OMP 18.1.13 measurements and scenario totals below remain useful evidence for their exact configuration. They do not measure 18.6.0, the newest model catalogue, or every provider connection.

A practical evaluation sequence

1. Record the HarnessRouter release, actual OMP executable version and model/provider route.
2. Confirm the OMP base is installed and visible in the server catalogue.
3. Run a small task whose expected artifact and tool use are easy to inspect.
4. Continue the same session and verify that required state survives.
5. Exercise the MCP or file behavior your application actually needs, including a denied or unavailable operation.
6. Recheck after any version override; retain the previous working image and data backup.

This is an acceptance plan, not a new successful run. Use HarnessRouter setup for the outer API, conformance for protocol behavior and FrontierHarness for a separate, frozen performance experiment. Adapter support is not native UHP adoption by Oh My Pi.

Historical source notes — baseline reviewed 17 Sep 2026

The following evidence preserves the earlier review and its links. “Current”, “stable” and “main” inside this section refer to that historical cutoff; they are not new release or compatibility claims. Use the guidance above for the current scope.

Current coordinates

Oh My Pi (omp) is an upstream agent harness from can1357/oh-my-pi. HarnessRouter added it as the tenth released backend in v0.15.0 through PR #68; Goose later became backend #11.

Coordinate	Verified state
HarnessRouter latest release	v0.17.2, tag target fa9ca27d
HarnessRouter checked runtime-relevant main	7e2c36a through PR #189; current repository head cc692866 is PR #190’s later conformance-evidence refresh and does not change the OMP adapter pin
HarnessRouter OMP adapter pin / measured binary	Oh My Pi 18.1.13
Upstream Oh My Pi latest release	v18.2.2, published 16 Sep 2026 at 16:29:05 UTC, tag target 60c9a115
Upstream Oh My Pi checked main	a2d83061, 43 commits ahead of v18.2.2 and zero behind at this cutoff
Released backend set	Eleven HarnessRouter backends; OMP remains backend #10
Dedicated OMP matrix	PR #119: 705/705 scenario runs across seven provider columns under its stated pre-release conditions
Current OMP tool catalog in HarnessRouter	Exactly ten hard-switch names accepted by measured 18.1.13: bash, read, write, edit, glob, grep, lsp, todo, task, web_search
Current MCP verification	PR #138 recognizes OMP MCP dispatch from stored write arguments using xd://mcp__<server>_<tool> and includes OMP in the real-MCP custom-harness dimension
Native upstream UHP adoption	Not established

The adapter pin and upstream latest release are deliberately separate. HarnessRouter’s measured 18.1.13 behavior should not be silently upgraded to v18.2.2 merely because the upstream project published newer behavior. Current HarnessRouter support-matrix evidence still documents the measured OMP 18.1.13 binary.

Upstream v18.2.2: secret handling, MCP liveness and approval fidelity

Oh My Pi published v18.2.2 on 16 September 2026 at 16:29:05 UTC. The tag points to 60c9a115b2e8decc0f75825459362d14188a8bc0. Checked upstream main is a2d83061c5d673bf3ee495d7652b63ee5a0ceb14, 43 commits ahead of the tag and zero behind at this cutoff, so post-release main work is not attributed to the stable release unless it is in the tag ancestry.

The v18.2.1 → v18.2.2 line adds several interoperability- and security-relevant harness behaviors:

• Secret obfuscation is broader. v18.2.2 recognizes credentials embedded in connection URLs regardless of environment-variable name and expands built-in redaction patterns across AWS access keys, Google API keys, Slack, npm, Stripe, Hugging Face, SendGrid, JWT, Bearer-token and PEM private-key forms. Explicit model refresh also re-evaluates command-backed API keys and headers so rotated credentials can take effect without restarting the harness.
• MCP request lifetime is less ambiguous. v18.2.2 fixes silent MCP requests being terminated by an undeclared idle timeout and makes closing a legacy SSE connection cancel pending requests and notifications. v18.2.1 also permits spaces in MCP server names through /mcp reauth write-back.
• Tool rewrites preserve the actual authority boundary. v18.2.1 lets an extension or hook return revised input from tool_call. The revised arguments are revalidated and become the arguments seen by concurrency scheduling, execution events/transcripts, persisted assistant history and the approval gate. A rewritten nested write xd://... dispatch forfeits the outer write approval and faces the full prompt again.
• Persistence and migration gain explicit conflict boundaries. Session rewrites refuse to replace a file modified by another process, and --from-claude / --from-codex can import external session histories, including Codex compaction state.

These are upstream Oh My Pi harness/runtime changes. They do not change UHP 2026-09-12, MCP, ACP or A2A wire semantics, do not move HarnessRouter’s measured OMP 18.1.13 coordinate, and do not establish native UHP adoption by Oh My Pi.

Prior v18.2.0: served-model identity and runtime interoperability hardening

Oh My Pi published v18.2.0 on 15 September 2026 at 04:39:58 UTC. The tag points directly to 6f2c14b3e4cc065139789da893e4f86f3d72958c. It is now superseded by v18.2.2; the behaviors below remain released upstream behavior.

The release promoted the previously tracked 18.2.0 development work and added several interoperability-relevant runtime changes:

• Served-model identity becomes explicit. Anthropic-compatible assistant turns can carry upstreamModel recovered from signed thinking blocks, and the transcript warns when a gateway serves a different Claude model than requested, including the requested model, served model and upstream route. This is provider-routing evidence inside the harness, not a new UHP identity field.
• MCP client internals converge on one response shape. Legacy parseSSE, MCPToolsResponse and MCPCallResponse helpers are removed; callMCP() now returns the shared JsonRpcResponse shape. Exa MCP calls also match responses after notifications, accept valid SSE framing and preserve cancellation. These are OMP client/runtime corrections, not an MCP specification revision.
• Failure and timing behavior is stricter. JavaScript Eval reports startup failure when both isolated runtimes fail instead of falling back to uncancellable host-thread execution. Very long automatic-retry waits are chunked so values beyond the signed 32-bit timer ceiling do not overflow and retry immediately. Hub wait timeouts identify the actual pending condition.
• Provider/catalog routing expands. The release adds provider policy/catalog support including DeepInfra, LiteLLM, Qwen Portal and SiliconFlow variants, adds Gemini 3.8 Flash data, accepts tiered OpenRouter @upstream selectors and adds Ollama-hosted web search plus Ollama model-page reads.

These are upstream Oh My Pi harness/provider/MCP-client behaviors. They do not change UHP 2026-09-12, MCP, ACP or A2A wire semantics, do not move HarnessRouter’s measured OMP 18.1.13 coordinate, and do not establish native UHP adoption by Oh My Pi.

Prior v18.1.22: collaboration promotion and runtime hardening

Oh My Pi published v18.1.22 on 14 September 2026 at 19:29:59 UTC. The stable tag points directly to 23a5b9ae38864d3f785dc6cbc96eb6d674a1d32d and is 133 commits ahead of v18.1.19 with zero behind. It is now superseded by v18.2.0; the behaviors below remain released upstream behavior.

The three-release rollup materially changed the maturity of behavior this site previously tracked only on post-v18.1.19 main:

• v18.1.20 promotes local collaboration discovery/capability handling to stable. collab.autoStart can auto-host a local interactive session, omp collab list / /collab list enumerate live hosts without exposing capability URLs, and omp collab link obtains one generation-bound URL. Room identity rotates across /new, /resume, fork and branch transitions. The release also fixes pending collaboration state around session changes and final background-task card delivery.
• v18.1.21 hardens browser automation. OMP normalizes Chromium profile paths, isolates OMP-owned browser profiles from an already-running Chrome, does not kill reused browser processes, keeps first-use browser installation outside Eval’s runtime timeout, reuses successful system-Chrome fallback and restores interaction with background OMP-owned tabs.
• v18.1.22 changes hub wait semantics and tightens sensitive diagnostics. Hub message/job waits now always use the adaptive 5-second-to-5-minute window and remove both the timeoutMs argument and async.pollWaitDuration. /debug memory reports now emit numeric memory statistics rather than raw heap snapshots that could expose provider or MCP credentials. Eval tool.todo(...) updates also persist through resume, rewind and fork.

These are upstream Oh My Pi harness/runtime changes. They do not change UHP 2026-09-12, MCP, ACP or A2A wire semantics, do not move HarnessRouter’s measured OMP 18.1.13 coordinate, and do not establish native UHP adoption by Oh My Pi.

Released by v18.1.22: LiteLLM capability evidence survives multi-endpoint discovery

Oh My Pi PR #11985 merged on 13 September 2026 at 79a7f19a0c300d2dad5fbcc6aaa7eed622605025 and is an ancestor of the current stable line.

OMP’s LiteLLM discovery reads four complementary management endpoints — /model_group/info, /v2/model/info, /model/info and /v1/model/info — and folds their partial rows into one model-group view. Before PR #11985, most capability axes already used declared-wins merging, but compat was taken wholesale from whichever later row reported supported_openai_params. A later partial endpoint could therefore erase compatibility evidence already established by an earlier endpoint.

The reproduced user-visible failure was image input. A deployment could report supports_vision: true and keep input: ["text", "image"], while the wholesale compatibility replacement dropped the strip opt-out derived from that declaration. OMP could then replace every attachment locally with [image omitted: model does not support vision] before a backend that actually accepted image_url content ever received it.

PR #11985 changes the merge to operate per compatibility axis: a later endpoint that does not report an axis contributes no new verdict rather than retracting an earlier declaration. The vision-derived strip override is preserved through the cascade. Follow-up ffc96d31 also keeps the supportsReasoningEffort axis tied to an endpoint that actually reported supported_openai_params, preventing an inferred model-class value from overwriting earlier explicit effort evidence.

Upstream reports 953 catalog tests passing and 4,637 AI-package tests passing, 332 skipped, 0 failed for the PR. The PR also records live operator evidence that /model/info declared vision support and that the affected LiteLLM/underlying routes accepted the image content, while OMP had stripped it client-side before the correction. The discovery cache namespace moves from rich-v8 to rich-v9 so warm rows are refetched under the corrected mapper.

This is OMP/LiteLLM provider capability-discovery and request-shaping correctness. It is not a LiteLLM, OpenAI, MCP, ACP, A2A or UHP wire-protocol change, does not move HarnessRouter’s measured OMP 18.1.13 coordinate, and does not establish native UHP adoption by Oh My Pi.

Released in v18.1.20: local collaboration host registry and capability links

PR #11908 merged as 4999b98bd51d5e9cd68be16af9b3a6dec1111865 on 13 September 2026 and is now stable upstream behavior through v18.1.20 and later releases.

PR #11908 adds two first-party primitives for local collaboration tooling. collab.autoStart can be off, view or control and defaults to off; an opted-in interactive session can publish itself without blocking startup. OMP also adds a private local host registry under ~/.omp/run/collab-hosts plus omp collab list / /collab list for metadata-only discovery and omp collab link <instanceId|pid> for the deliberate capability-bearing URL step. Listings do not expose the URL itself.

Session identity changes are generation-bounded. On /new, /resume, fork or branch transitions, OMP stops the old room first, sends bye, withdraws the old registry entry and only then starts the successor. Link requests are checked against the requested access level and exact generation, so stale discovery metadata cannot silently mint a capability for a replacement session. The host also refuses collaboration traffic for a session it never shared, tightens the registry directory to owner-only access and rejects symlink/foreign-owner registry directories on the covered platforms.

This is a local host-discovery and collaboration-capability boundary inside OMP, not a new collaboration wire protocol. Upstream explicitly leaves COLLAB_PROTO, relay-server behavior, wire frames, link format and encryption unchanged, and this first version adds no daemon. It is therefore not an MCP, ACP, A2A or UHP wire change, does not move HarnessRouter’s measured OMP 18.1.13 coordinate and does not establish native UHP adoption by Oh My Pi.

Upstream reports 718 focused tests across 78 files plus package checks and real CLI/TUI/relay/registry smoke coverage. The merge-head Actions run had ten passing jobs while workspace-fast failed on unchanged upstream Yolo-Auto catalog assertions; Windows named-pipe and cross-user NTFS ACL behavior was not exercised natively in that PR. Stable release promotion does not erase those original verification boundaries.

Released by v18.1.22: OpenCode Muse Spark encrypted-reasoning replay

PR #11931 merged as 165cede8400d833382177a4dfd2901271c9f0a2c on 13 September 2026 and is now in the stable ancestry.

The reproduced failure affected Muse Spark reasoning models routed through the OpenCode Zen and OpenCode Go gateways. A tool-using first step could succeed, then the tool-result continuation could fail with HTTP 400 because OMP requested and replayed provider-native encrypted reasoning that the gateway could not round-trip to the same upstream caller context.

OMP now applies a Muse Spark compatibility policy on opencode-zen and opencode-go that disables encrypted-reasoning inclusion and filters reasoning history before replay. Upstream reports 90 focused tests passing, including both gateway lanes and a sibling reasoning model that retains the normal Responses defaults.

This is a provider/harness request-replay compatibility correction. It is not an OpenAI Responses, MCP, ACP or UHP wire change, does not move HarnessRouter’s measured OMP 18.1.13 coordinate, and does not establish native UHP adoption by Oh My Pi.

Prior v18.1.19: stable promotion of reliability and automation work

Oh My Pi published v18.1.19 on 12 September 2026 at 23:57:09 UTC. The stable tag points to e4dd2ec3b487f216c569281e2cdb7ec476a81f2e. It is now superseded by v18.2.0; its behaviors remain in the later stable line. The release promoted the previously tracked post-v18.1.18 MCP reconnect, provider-retry, DeepSeek V4.1 Flash, fallback-effort, /btw and JSON print-mode work into stable behavior; ancestry from the prior checked e109c5a6 checkpoint was direct, with v18.1.19 thirteen commits ahead and zero behind.

The release also adds Agent.getPendingToolResults() so hosts can rebuild a live display before buffered tool results are persisted, and fixes completed tool cards reverting to pending after live-session refocus. Speculative execution is tightened so a stream session planned for one call is discarded when a hook or argument transform replaces the call arguments while retaining the same call id. These are harness display/execution-finality controls, not UHP or MCP wire changes.

Provider/authentication fixes include accepting valid Codex OAuth account tokens that expose an email but omit chatgpt_account_id, correcting Windows zcode:// callback registration so Z.AI coding-plan browser authorization can actually launch the native callback handler, and fixing Kimi Code usage-limit classification. OMP also exposes public OS-backed file-lock APIs and fixes its Windows PowerShell 5.1 installer path. These are upstream OMP runtime/platform behaviors, not HarnessRouter adapter revalidation.

The release did not move HarnessRouter’s measured OMP coordinate. Current HarnessRouter evidence still binds the published OMP matrix/tool/MCP evidence to measured 18.1.13.

Prior v18.1.18: remote compaction, session scoping and task recovery

Oh My Pi published v18.1.18 on 11 September 2026 at 21:43:45 UTC. The release tag points to 00085d4e7dfdcfbf302c122fa2682b410a0f43d1. It is now superseded by v18.2.0; the behaviors below remain released upstream behavior.

Anthropic server-side compaction becomes a normal remote method

The release adds first-party Anthropic server-side compaction under OMP’s existing remote-compaction path. The low-level AI package exposes the compact-2026-01-12 beta through anthropicCompaction / compact_20260112; the coding agent can select it through the existing compaction.methodOrder and compaction.remoteEnabled controls.

The native result is persisted as both readable summary text and an opaque provider replay payload, then replayed as an Anthropic compaction block on later turns. Capability and endpoint checks gate the feature: unsupported, older or rerouted models fall back to the text-summary path instead of assuming the native wire contract. Provider-native compaction also reissues the actual live system prompt, including a per-turn before_agent_start override, rather than compacting against a stale/default prompt.

That is a harness/provider context-management boundary. It does not add a UHP task/session primitive and does not change MCP or ACP wire semantics.

Queue-mode RPC setters are session-scoped

set_steering_mode, set_follow_up_mode and set_interrupt_mode no longer let a short-lived RPC client mutate the machine-global config.yml queue-mode values. The setters now apply to the active session.

This matters for multi-session isolation: one automation/control client can change how its current session handles steering/follow-up/interrupt input without silently changing the default for unrelated future sessions.

Isolated-task recovery preserves nested-repository work

When an isolated task modifies nested repositories that cannot be folded cleanly into the normal task result, OMP now persists recovery patches named like <agent>.nested-*.patch. apply=false reports the files, and runs that require manual recovery fail visibly rather than presenting a clean success while dropping nested-repository work. Isolated agents are also treated as non-resumable.

This is harness-level durability/finality behavior, not UHP artifact semantics.

/mcp reload distinguishes connecting from inactive

/mcp reload now reports servers that are still connecting after its bounded reload window instead of collapsing that state into “zero active”. This is operational MCP-client liveness/reporting inside OMP; it does not change the MCP protocol.

Released in v18.1.19: MCP reconnects release obsolete tool generations

PR #11787 fixes a long-session resource-retention defect in the real SessionTools.refreshMCPTools reconnect/refresh path. Upstream’s source-level reproduction repeatedly constructed 500 MCP tools for 280 refresh generations: before the fix, forced-GC heap usage grew from about 25.0 MB to 165.5 MB, while old tool/context objects accumulated across generations. After the fix, the same churn held heap usage around 25.0–25.5 MB with stable object counts.

The root cause was refresh-local closure state retained by live CustomToolAdapter instances, which kept rollback maps and earlier wrapper generations reachable. The correction moves the custom-tool context factory to session lifetime and clears previousMcpTools immediately after a successful refresh commit while preserving rollback/disposal behavior. Upstream regression verification reports 41 tests / 180 assertions plus bun check passing.

This is an Oh My Pi MCP-client/runtime resource-lifetime and long-session reliability correction. It does not change MCP wire semantics, UHP behavior, or HarnessRouter’s separately measured OMP 18.1.13 adapter evidence.

Released in v18.1.19: DeepSeek V4.1 Flash wire fidelity

PR #11799 moves the bare deepseek-flash alias onto the V4.1 Flash wire contract. Upstream records the important transport consequences: tool-choice support is disabled for that route, replay flags are enabled, and the route uses max_tokens plus reasoning_content semantics expected by DeepSeek V4.1 Flash.

This correction is released upstream behavior and remains separate from HarnessRouter’s measured OMP 18.1.13 adapter coordinate.

Released in v18.1.19: incomplete tool-call starts remain replay-safe

PR #11823 fixes a provider-stream failure mode where a transport reset could arrive after toolcall_start but before any argument content. Previously, OMP could finalize the incomplete block as an empty {} tool call, treat the attempt as committed, refuse replay and then fail argument validation with errors such as a missing path.

The retry boundary now treats toolcall_start and toolcall_end markers alone as uncommitted. A failed attempt can therefore discard those buffered lifecycle markers and retry before any tool has executed. A non-empty toolcall_delta still commits the attempt, including a string-argument host emitting {} for a legitimate zero-argument call, so already actionable tool calls are not silently replayed after a later transport failure.

This is a harness/provider replay-safety and tool-execution finality correction. It does not change MCP tool-call semantics, UHP response semantics or HarnessRouter’s measured OMP adapter coordinate.

Released in v18.1.19: fallback models can pin their own reasoning effort

PR #11842 extends OMP’s retry fallback chains so a concrete fallback selector can carry an explicit thinking suffix such as openai/gpt-5-mini:low. A bare fallback continues to inherit the failing turn’s effort, and provider/* fallback entries always inherit. The /models UI can set or clear the per-entry effort; new picks stay bare by default, and :auto collapses to inherited behavior rather than becoming a separate fallback policy.

This matters when failover moves between model families with different useful reasoning budgets: the fallback chain can now specify the intended effort per concrete backup instead of forcing every backup to inherit the primary turn’s setting. It remains OMP runtime/model-routing behavior, not a provider protocol, UHP negotiation primitive or HarnessRouter revalidation.

Released in v18.1.19: /btw side conversations persist outside the main context

PR #11335 turns /btw from a single transient side answer into session-local persistent side-conversation history. A bare /btw reopens the history/details panel, completed answers can be followed up, multiple topics can remain available, cancelled requests retain partial output, and unfinished records reopen as interrupted rather than being replayed automatically.

The context boundary is explicit: side conversations stay outside the main transcript and model context. Follow-ups preserve separate user/assistant messages and reuse an isolated topic-specific provider session for cache reuse; cancellation or failure rotates to a fresh transport generation instead of reusing an uncertain provider conversation.

The merge also tightens persistence and transition safety. OMP rejects stale cross-process writes, protects active topics with an OS-backed per-topic lease, and settles or refuses around pending /btw writes before session selection/deletion, extension-driven create/switch/branch operations and working-directory/worktree relocation. Failed terminal saves block those session operations rather than being reported as a successful flush. Upstream reports 186 focused tests across 12 files plus package checks and direct TUI exercise.

This is an OMP-internal auxiliary-context/session-isolation and persistence boundary. It is not a UHP Session or Task primitive, does not alter MCP or ACP wire semantics, and does not update HarnessRouter’s separately measured OMP 18.1.13 adapter evidence.

Released in v18.1.19: JSON print mode returns a failing process status

PR #11545 corrects a headless-automation failure contract in OMP’s non-interactive print mode. Before the fix, --mode json could emit a turn-fatal provider, authentication or network error in its JSON event stream and still terminate with exit code 0. The text path inspected the terminal stopReason and hard-exited on failure, while JSON mode fell through normal cleanup and main.ts unconditionally ended with success.

The corrected path computes terminal failure independently of output format. runPrintMode returns 1 for a failed turn and 0 otherwise, and main.ts propagates that value as the process exit status. JSON mode keeps stderr clean because the structured event stream already carries the error. The change also preserves bounded advisor/telemetry cleanup and ensures session.dispose() completes before process termination instead of bypassing or duplicating disposal on the failure path.

Upstream verification reports 20 passing tests / 0 failures / 62 assertions across five focused files, plus the plan-startup-hang regression test. For pipelines and supervising harnesses this is material: a JSON consumer can now use the ordinary process status as a reliable failure gate instead of parsing event payloads merely to distinguish a dead turn from success.

This is an Oh My Pi CLI/headless process contract. It does not change UHP response status semantics, MCP/ACP wire behavior, HarnessRouter’s separately measured OMP 18.1.13 adapter evidence or native UHP adoption.

Prior v18.1.17: context integrity, skill isolation and collaboration recovery

Oh My Pi published v18.1.17 on 10 September 2026 at 19:33:46 UTC at tag 3b3a6dc9bbd85102ce19d0b1c11bf6870915f6ec. It is now superseded by v18.2.0; the changes below remain released upstream behavior.

Context budgeting and repeated-compaction integrity

The @oh-my-pi/pi-agent-core release fixes the token estimator so developer messages and user images count toward transcript size. Before this correction, context budgeting, pruning and compaction could treat the transcript as materially smaller than the payload actually sent to the provider.

The same release fixes repeated local/soft compaction so messages retained by the previous compaction pass remain in later model context instead of being silently omitted. Original entry IDs and /clear boundaries are preserved. Remote compaction timeout also increases from three to five minutes so long Codex / gpt-6-astra compact streams have more time to complete.

These are harness-context reliability changes. They do not alter UHP task/session semantics or HarnessRouter’s measured OMP 18.1.13 adapter evidence.

Declared-skill loading stays scoped to the marketplace plugin

v18.1.17 fixes marketplace plugins that share one repository root so each plugin loads only its declared skills, rather than every skill discoverable in that repository. This is a meaningful harness trust/isolation boundary: repository co-location no longer implies cross-plugin skill exposure.

This is Oh My Pi plugin-discovery behavior, not MCP or UHP capability negotiation and not evidence that HarnessRouter maps plugin skill declarations through UHP.

Collaboration UI requests survive guest timing and reconnects

Oh My Pi collaboration now retains up to 64 pending host UI requests raised before a writable guest joins and replays them only to writable guests. Already-aborted requests no longer consume request IDs. A writable guest that reconnects and resends an answer for an already-settled request now receives a targeted ui-request-end, preventing that guest from waiting indefinitely after missing the earlier broadcast.

This is product-level collaboration recovery/finality inside OMP. It is not A2A, ACP or UHP wire behavior.

Unknown-tool recovery remains advisory

When the advertised tool set contains a plausible intended target, Tool <name> not found can now include a suggestion derived from the recognizable trailing segment of an opaque name. Upstream explicitly keeps the suggestion advisory only: the unrecognized name still fails and the suggested string is never dispatched automatically.

That distinction matters for safety and evidence. The release improves same-turn model recovery without turning fuzzy name matching into tool authority.

Optional plan persistence

The coding-agent package also adds opt-in plan.autosave. Approved plans can be written to <project>/.omp/plans/ or a configured plan.autosaveDir. This is local harness artifact persistence, not a UHP resource or session primitive.

Prior v18.1.16: context rollover, loop gates and Codex recovery

The preceding v18.1.16, published 9 September 2026 at 19:05:50 UTC, points to 61b1b8aef634334eaf1412afd003a763e1d1b9c1. That coordinate is now superseded by v18.2.0; the three runtime changes below remain part of released upstream behavior.

Experimental notes-backed context windows

PR #10893 adds an off-by-default context-management path behind compaction.experimentalContextManagement. Instead of relying only on ordinary transcript compaction, an agent can maintain a branch-local context_notes notebook, request a fresh context window through new_context, and read or grep the original branch history through history://current/full.

The notebook is bounded to 16 KiB UTF-8, persists in the session journal and survives context-window rollover. That is a concrete harness-level continuity mechanism: selected working state can live outside the current model context while full history remains addressable through the virtual history path. Upstream explicitly labels the feature experimental and does not establish a general long-session quality, latency or cost improvement from the mechanism yet.

Conditional /loop execution

PR #10858 extends OMP’s /loop command with --while '<cmd>' and --until '<cmd>' gates. The shell condition is re-evaluated before each iteration through OMP’s normal shell execution path. Exit status is authoritative, stdout is ignored, exit codes above 1 stop with a distinct error, and the existing iteration/time budget can still cap the loop.

This makes OMP’s loop product-specific control responsive to external state—for example, continuing while unchecked work remains in a task file—instead of relying only on a fixed count or duration. It is relevant to loop engineering, but it is not a UHP loop primitive or protocol change; UHP 2026-09-12 still leaves outer recurrence and stopping policy to the caller/runtime.

Replay-safe recovery for truncated Codex streams

PR #11356 moves missing Codex terminal-event handling into OMP’s provider retry path. A stream that ends without response.completed / response.done is treated as a transient truncation when safe to retry. Empty/uncommitted output can retry in place, while output already committed to the conversation is not replayed, avoiding duplicate side effects or text. The same handling recognizes truncation during continuation after a resolved tool turn.

This is an OMP/Codex provider-runtime reliability change. It does not alter Codex’s protocol, MCP wire semantics, UHP semantics or HarnessRouter’s measured OMP adapter coordinate.

v0.15.6: tool-catalog and MCP correctness

PR #135 corrects two concrete Oh My Pi integration assumptions in HarnessRouter.

First, URL-based MCP entries are now written with type: "http". Second, HarnessRouter no longer advertises python and browser as OMP hard-switch tools. The PR records that the measured Oh My Pi 18.1.13 binary rejects both names when supplied through its tool-selection flag even though HarnessRouter had previously exposed them in its catalog.

The corrected hard-switch catalog is exactly:

bash
read
write
edit
glob
grep
lsp
todo
task
web_search

HarnessRouter also sends an explicit OMP allowlist only when the configured policy actually removes one of those native tools. This avoids converting a no-op policy into an unnecessary hard switch.

PR #138 then extends the custom-harness verification dimension to a real MCP server. For OMP, HarnessRouter recognizes the stored MCP dispatch when OMP routes through write with a path shaped like xd://mcp__<server>_<tool>. The dimension requires the second turn to call the declared MCP server and judges the stored call rather than trusting remote prose.

The PR’s candidate run reports the MCP dimension across all ten built-in harness bases at that historical point, including OMP, when the external endpoint is reachable. This is stronger implementation evidence than the earlier “MCP untested” state, but it is still not UHP conformance and not a guarantee that every arbitrary MCP server/tool combination works through OMP.

v0.15.0: tenth released backend

PR #68 adds OMP as a first-class HarnessRouter backend. The adapter installs the Oh My Pi binary, writes per-session model/MCP configuration, maps provider credentials and model routes, resumes existing sessions and normalizes OMP’s progressive JSON event stream into HarnessRouter’s task/turn response path.

HarnessRouter’s OMP backend support means the reference implementation can drive Oh My Pi. It does not mean the upstream Oh My Pi project independently implements UHP.

PR #119: dedicated OMP compatibility evidence

PR #119 records a dedicated pre-release support-matrix run using Oh My Pi 18.1.13. The published scenario totals are:

Provider column	Scenario runs
Google AI Studio	55 / 55
OpenRouter	184 / 184
Vercel AI Gateway	184 / 184
TokenRouter	164 / 164
Anthropic	40 / 40
OpenAI	39 / 39
Azure OpenAI E2	39 / 39
Total	705 / 705

That evidence is adapter/runtime compatibility, not the UHP conformance suite. It also predates PR #135’s tool-catalog correction and PR #138’s real-MCP custom-harness dimension, so those later findings should be recorded separately rather than retroactively changing the 705/705 denominator.

Evidence boundaries

Keep nine different claims separate:

1. UHP conformance: the current 2026.9.12 suite has 74 checks. HarnessRouter’s current release-verification, checked-in README remeasurement and checked JSON report each record 74/74 Full as separate evidence events; none is the OMP support matrix.
2. Broad HarnessRouter matrix: PR #93 covers 695 harness × model pairs across the eight backends that existed before Gemini CLI and OMP were released.
3. OMP-specific matrix: PR #119 records 705/705 scenario runs for OMP under its stated conditions using 18.1.13.
4. Custom-harness MCP dimension: PR #138 adds a real MCP call and includes OMP dispatch recognition. This is a different runtime-verification dimension.
5. Upstream OMP stable v18.2.2: secret-obfuscation expansion, command-backed credential refresh, silent-MCP request-lifetime repair, legacy-SSE cancellation and the v18.2.1 approval-preserving tool-input rewrite path are released upstream behavior. They are not HarnessRouter revalidation of OMP 18.1.13.
6. Upstream OMP v18.2.0 and earlier: served-model identity, MCP response-shape/SSE/cancellation cleanup, collaboration promotion, browser automation hardening, compaction/session/task-recovery and prior context/skill/loop/replay changes remain separately version-bounded released behavior.
7. Current upstream main: a2d83061 is 43 commits ahead of v18.2.2 at this cutoff; post-release current-main work must not be silently attributed to the stable release.
8. Harness Plugins: UHP 2026-09-12 adds an optional plugin sub-protocol, but current HarnessRouter OMP adapter evidence does not establish that OMP itself consumes or implements that protocol natively.
9. Native adoption: upstream Oh My Pi public sources still do not establish native UHP implementation.

Why native adoption remains unverified

A UHP server can adapt a CLI/harness without the upstream project changing its own public API. The reviewed primary Oh My Pi sources establish the upstream harness and its releases; HarnessRouter sources establish the adapter. They do not establish that Oh My Pi itself exposes or consumes UHP natively.

Caution

The acronym OMP is overloaded on this site. In HarnessRouter backend context, omp means Oh My Pi. The separate UHP vs OMP page covers the unrelated Open Memory Protocol family.

Related pages

Read HarnessRouter Community Edition, Harness Plugins, loop engineering, DeepSeek Harness, conformance, release tracker, ecosystem, adoption and UHP vs MCP.

Primary sources

• Oh My Pi repository
• Oh My Pi v18.2.2
• Oh My Pi v18.2.2 tag 60c9a115
• Oh My Pi coding-agent changelog at v18.2.2
• Oh My Pi checked current main a2d83061
• Oh My Pi v18.2.0
• Oh My Pi v18.2.0 tag 6f2c14b3
• Oh My Pi coding-agent changelog at v18.2.0
• Oh My Pi AI/provider changelog at v18.2.0
• Oh My Pi catalog changelog at v18.2.0
• Oh My Pi v18.1.22
• Oh My Pi v18.1.22 tag 23a5b9ae
• Oh My Pi coding-agent changelog at v18.1.22
• Oh My Pi PR #11985 — merge LiteLLM compatibility evidence per axis
• Oh My Pi PR #11908 — local collab host registry and capability links
• Oh My Pi PR #11931 — OpenCode Muse Spark encrypted-reasoning replay
• Oh My Pi v18.1.19
• Oh My Pi v18.1.19 tag e4dd2ec3
• Oh My Pi coding-agent changelog at v18.1.19
• Oh My Pi agent-core changelog at v18.1.19
• Oh My Pi AI/provider changelog at v18.1.19
• Oh My Pi v18.1.18
• Oh My Pi v18.1.18 tag target 00085d4e
• Oh My Pi PR #11787 — release obsolete MCP tool generations after reconnect
• Oh My Pi PR #11799 — DeepSeek V4.1 Flash wire contract
• Oh My Pi PR #11823 — replay-safe retry for empty tool-call starts
• Oh My Pi PR #11842 — per-fallback reasoning effort
• Oh My Pi PR #11335 — persistent /btw history and follow-ups
• Oh My Pi PR #11545 — JSON print-mode failure exit status
• Oh My Pi PR #11868 — live tool-result display continuity
• Oh My Pi PR #11847 — Codex OAuth account-id compatibility
• Oh My Pi PR #11907 — Windows zcode:// OAuth callback fix
• Oh My Pi v18.1.17
• Oh My Pi v18.1.17 tag target 3b3a6dc9
• Oh My Pi v18.1.16
• Oh My Pi v18.1.16 tag target 61b1b8ae
• PR #10893 — experimental notes-backed context windows
• PR #10858 — conditional /loop gates
• PR #11356 — truncated Codex stream recovery
• Oh My Pi v18.1.13
• HarnessRouter v0.17.2
• HarnessRouter v0.17.2 tag target fa9ca27d
• HarnessRouter runtime-relevant main through PR #189 7e2c36a
• HarnessRouter current repository head cc692866
• HarnessRouter OMP pin/evidence at current head
• PR #182 — retain dsh stdio MCP servers in the hosted job
• PR #181 — backend-native MCP transport fidelity
• PR #180 — post-release Pi/dsh plugin stdio parity
• PR #175 — UHP 2026-09-12 Harness Plugins implementation
• PR #138 — custom-harness real-MCP verification
• PR #135 — OMP tool/MCP corrections
• HarnessRouter v0.15.0
• PR #119 — OMP support-matrix evidence
• PR #68 — Oh My Pi backend
• PR #93 — historical eight-backend support matrix
• Current UHP conformance suite