feat: add OMP (Oh My Pi) coding agent support

[KorenKrita]

Summary

Adds OMP (Oh My Pi coding agent, @oh-my-pi/pi-coding-agent) as a first-class agent flavor, with feature parity to the Claude Code integration on the core loop and OMP's unique capabilities surfaced through hapi's existing generic channels (no reducer or RPC-architecture changes).

What is included

Shared layer

• 'omp' added to AGENT_FLAVORS; OMP_PERMISSION_MODES = ['yolo'] (OMP rpc mode has no runtime permission switching — --approval-mode is fixed at spawn).
• FLAVOR_CAPS / FLAVOR_LABELS entry; getPermissionModesForFlavor('omp') returns the yolo-only list.
• RPC_METHODS.ListOmpModels + OMP superset RPC method constants (OmpCompact, OmpSetSteeringMode, OmpSetInterruptMode, OmpSetFollowUpMode, OmpCycleModel, OmpCycleThinkingLevel, OmpGetSessionStats).
• OmpModelSummary / OmpModelsResponse / OmpCommandSummary types (thinking info carried as efforts array + effortMap + defaultLevel, matching OMP's Model.thinking shape).
• MetadataSchema gains ompSessionId / ompSessionFile / ompAvailableModels / ompSelectedModel.

CLI (cli/src/omp/, new directory)

OMP speaks the same JSONL-over-stdio RPC family as Pi (shared @oh-my-pi/pi-agent-core + pi-ai), so the module mirrors the existing per-agent directory layout. Protocol-specific differences handled:

• ready handshake gate — OMP emits {"type":"ready"} before accepting commands; the transport buffers sends until ready (with a 10s timeout + immediate reject on spawn ENOENT).
• Slash commands via push — OMP streams available_commands_update frames; the loop caches them and falls back to get_available_commands.
• Model thinking extraction — schemas read model.thinking.efforts / effortMap / defaultLevel (per-model level list), not a flat map.
• Resume — --continue flag (OMP's SessionManager.continueRecent); new_session is skipped on resume so the restored context is not discarded.
• Binary resolution — resolveOmpCommand() finds ~/.bun/bin/omp (the bun global install symlink is often off-PATH).
• Spawn flags — --approval-mode yolo fixed at spawn.

OMP-only events map onto hapi's existing generic web events (no new event types):

• goal_updated -> thread_goal_updated (with budget-limited -> budgetLimited, dropped/null -> thread_goal_cleared), reusing the latestGoal reducer + presentation.
• auto_compaction_start/end -> compact event.
• thinking_level_changed -> updates session state + keepAlive (validated against the thinking-level enum).
• subagent frames -> sidechain messages (reuse the existing isSidechain / parentUUID tracer).
• Other events (todo_reminder, notice, auto_retry_*, ttsr_triggered, ...) pass through the AgentEvent catch-all.

Single-direction superset RPCs registered in runOmp: compact, steering/interrupt/follow-up mode switches, cycle model/thinking level, session stats.

Hub

• callOmpRpc in rpcGateway + syncEngine; withOmpSession flavor guard + GET /sessions/:id/omp-models route.
• extractAgentSessionId recognizes ompSessionId.

Web

• useOmpModels hook + callOmpEndpoint client method + sessionOmpModels query key.
• OmpModelPanel + ompModelGroups (provider grouping).
• OmpThinkingLevelPanel + ompThinkingLevelOptions — filters levels by the model's efforts array (case-insensitive).
• HappyComposer conditional rendering for the omp flavor; SessionChat wires the model query + metadata; AgentFlavorIcon omp badge; NewSession MODEL_OPTIONS entry; locales.

Out of scope

host_tool_call / host_uri_request / extension_ui_request are OMP's extension-ecosystem hooks — OMP does not send them unless the host registers tools/URI schemes, so they are not wired in this PR.

Tests

• cli/src/omp/: 5 test files (schemas, accumulator, converter, transport, loop) — 80 tests covering the ready gate, markReady killed-guard, ENOENT rejecting ready() immediately, close-event code/signal delivery, goal field mapping, initialModelApplied race guard, malformed-response skipping, schema fault tolerance.
• web/: ompThinkingLevelOptions.test.ts — 13 tests covering efforts filtering, case normalization, dedup, non-standard current-level retention.

Verification

• bun typecheck — 0 errors across cli/hub/web.
• bun run test — 80/80 omp tests + 13/13 web tests pass; full non-integration suite 1188/1188 pass.
• Live smoke: OmpTransport spawn -> ready handshake -> prompt -> streaming text deltas -> turn_complete, confirmed against a real OMP process.

The only failing test in the suite is the pre-existing runner.integration.test.ts > stress test: spawn/stop flake; this branch does not touch runner code.

Files

• 13 new files (cli/src/omp/ source + tests, cli/src/commands/omp.ts, web Omp panels + hook + tests)
• 19 modified files (shared enums/types/schema, hub rpc gateway + routes + cache, web client + composer + session chat + types)

[github-actions]

Findings

• [Blocker] OMP web launches still spawn Claude — adding omp to the shared flavor list makes it selectable in New Session, but runner spawn argument construction has no omp branch, so buildCliArgs('omp', ...) falls through to claude. Creating an OMP session from the web/runner will start Claude instead of hapi omp. Evidence shared/src/modes.ts:10, related context cli/src/runner/run.ts:1076.
  Suggested fix:

  const agentCommand = agent === 'codex'
      ? 'codex'
      : agent === 'cursor'
          ? 'cursor'
          : agent === 'gemini'
              ? 'gemini'
              : agent === 'kimi'
                  ? 'kimi'
                  : agent === 'opencode'
                      ? 'opencode'
                      : agent === 'pi'
                          ? 'pi'
                          : agent === 'omp'
                              ? 'omp'
                              : 'claude'
  
  if (options.effort && (agent === 'claude' || agent === 'pi' || agent === 'omp')) {
      args.push('--effort', options.effort)
  }

• [Major] OMP resume metadata is written but not used by resume flows — this PR adds ompSessionId, but resolveAgentResumeId() and the web-side resolveAgentSessionIdFromMetadata() still fall through to Claude for flavor === 'omp'; hapi resume also has no OMP dispatch branch and would fall through to Cursor once the hub starts returning OMP targets. Inactive OMP sessions with messages therefore show/return resume unavailable instead of using the stored OMP id. Evidence shared/src/schemas.ts:53, related context hub/src/sync/syncEngine.ts:752 and cli/src/commands/resume.ts:165.
  Suggested fix:

  // hub/src/sync/syncEngine.ts
  if (flavor === 'omp') return metadata.ompSessionId ?? null
  
  // web/src/lib/sessionResume.ts
  case 'omp': return metadata.ompSessionId ?? undefined
  
  // cli/src/commands/resume.ts
  if (target.flavor === 'omp') {
      const { runOmp } = await import('@/omp/runOmp')
      await runOmp({
          existingSessionId: base.existingSessionId,
          workingDirectory: base.workingDirectory,
          resumeSessionId: base.resumeSessionId,
          startedBy: base.startedBy,
          startingMode: 'remote',
          model: target.model ?? undefined,
          effort: target.effort ?? undefined,
      })
      return
  }

Summary

• Review mode: initial
• OMP core loop has coverage, but the flavor is not fully wired into runner spawn/resume entrypoints yet.

Testing

• Not run (automation)

HAPI Bot

[github-actions]

[BLOCKER] Adding omp here exposes it through New Session, but the runner's buildCliArgs() has no omp branch and currently maps unknown agents to claude, so web/runner-created OMP sessions start Claude instead of OMP.

Suggested fix:

const agentCommand = agent === 'codex'
    ? 'codex'
    : agent === 'cursor'
        ? 'cursor'
        : agent === 'gemini'
            ? 'gemini'
            : agent === 'kimi'
                ? 'kimi'
                : agent === 'opencode'
                    ? 'opencode'
                    : agent === 'pi'
                        ? 'pi'
                        : agent === 'omp'
                            ? 'omp'
                            : 'claude'

[github-actions]

[MAJOR] ompSessionId is stored, but the resume helpers do not read it yet. SyncEngine.resolveAgentResumeId() still falls through to Claude for OMP, the web resolveAgentSessionIdFromMetadata() does the same, and hapi resume has no OMP dispatch branch. Inactive OMP sessions with messages will be treated as non-resumable.

Suggested fix:

if (flavor === 'omp') return metadata.ompSessionId ?? null

case 'omp': return metadata.ompSessionId ?? undefined

if (target.flavor === 'omp') {
    const { runOmp } = await import('@/omp/runOmp')
    await runOmp({ existingSessionId: base.existingSessionId, workingDirectory: base.workingDirectory, resumeSessionId: base.resumeSessionId, startedBy: base.startedBy, startingMode: 'remote', model: target.model ?? undefined, effort: target.effort ?? undefined })
    return
}

[github-actions]

Findings

• [Major] OMP resume uses “most recent” instead of the selected session — resolveAgentResumeId() returns ompSessionId, but runOmp() only turns any resume id into --continue, which OMP resolves as the most recent session in that cwd-derived directory. If a directory has more than one OMP session, hapi resume <session-id> / web resume can attach the wrong conversation even though metadata also stores ompSessionFile. Evidence cli/src/omp/runOmp.ts:72, related context hub/src/sync/syncEngine.ts:759.
  Suggested fix:

  // hub/src/sync/syncEngine.ts
  if (flavor === 'omp') return metadata.ompSessionFile ?? metadata.ompSessionId ?? null
  
  // cli/src/omp/runOmp.ts, after transport.ready()
  if (opts.resumeSessionId) {
      transport.send({ type: 'switch_session', sessionPath: opts.resumeSessionId })
  } else {
      transport.send({ type: 'new_session' })
  }

• [Major] OMP permission mode control always fails for active sessions — OMP exposes a yolo permission option, so the composer renders a permission-mode action and posts /permission-mode; the hub forwards { permissionMode: 'yolo' } through SetSessionConfig, but the OMP handler never includes permissionMode in applied, so applySessionConfig() rejects with Session did not apply permissionMode. Evidence shared/src/modes.ts:133, related context cli/src/omp/runOmp.ts:235.
  Suggested fix:

  const appliedPermissionMode = config.permissionMode === undefined ? undefined : 'yolo'
  if (config.permissionMode !== undefined && config.permissionMode !== 'yolo') {
      throw new Error('Invalid permission mode')
  }
  
  return {
      applied: {
          ...(appliedPermissionMode ? { permissionMode: appliedPermissionMode } : {}),
          model: appliedModel,
          effort: ompSession.currentThinkingLevel,
      },
  }

Summary

• Review mode: follow-up after new commits
• The previous runner-spawn and resume-dispatch findings are fixed in the latest head. Remaining issues are in OMP resume precision and the newly exposed OMP permission-mode path.

Testing

• Not run (automation)

HAPI Bot

[github-actions]

[MAJOR] OMP resume uses “most recent” instead of the selected session. resolveAgentResumeId() currently returns ompSessionId, but this branch ignores the id and only starts OMP with --continue, which OMP resolves as the most recent session in the cwd-derived directory. If the same directory has multiple OMP sessions, hapi resume <session-id> / web resume can attach the wrong conversation even though metadata stores ompSessionFile.

Suggested fix:

// hub/src/sync/syncEngine.ts
if (flavor === 'omp') return metadata.ompSessionFile ?? metadata.ompSessionId ?? null

// cli/src/omp/runOmp.ts, after transport.ready()
if (opts.resumeSessionId) {
    transport.send({ type: 'switch_session', sessionPath: opts.resumeSessionId })
} else {
    transport.send({ type: 'new_session' })
}

[github-actions]

[MAJOR] This exposes a yolo permission-mode option for OMP, so the composer posts /permission-mode; for active sessions the hub forwards { permissionMode: 'yolo' } into OMP SetSessionConfig. The OMP handler never returns permissionMode in applied, so applySessionConfig() rejects with Session did not apply permissionMode and the visible control always fails.

Suggested fix:

const appliedPermissionMode = config.permissionMode === undefined ? undefined : 'yolo'
if (config.permissionMode !== undefined && config.permissionMode !== 'yolo') {
    throw new Error('Invalid permission mode')
}

return {
    applied: {
        ...(appliedPermissionMode ? { permissionMode: appliedPermissionMode } : {}),
        model: appliedModel,
        effort: ompSession.currentThinkingLevel,
    },
}

[github-actions]

Findings

• [Major] OMP resume silently creates a fresh conversation when exact restore fails — when switch_session rejects or times out, this fallback sends new_session inside the existing HAPI session row. A missing/moved ompSessionFile or transient OMP RPC failure would make hapi resume <session-id> / web resume appear successful while the user is actually in an empty OMP conversation, risking prompts being sent with no prior context. Evidence cli/src/omp/runOmp.ts:490.
  Suggested fix:

  if (opts.resumeSessionId) {
      await sendOmpRpcAndWait(ompSession, transport, {
          type: 'switch_session',
          sessionPath: opts.resumeSessionId,
      })
  } else {
      transport.send({ type: 'new_session' })
  }

Questions

• None.

Summary

• Review mode: follow-up after new commits
• The prior exact-resume and OMP permission-mode findings are addressed, but the new resume fallback still lets a failed exact restore continue as a fresh OMP session under the selected HAPI session.

Testing

• Not run (automation)

HAPI Bot

[github-actions]

[MAJOR] OMP resume silently creates a fresh conversation when exact restore fails. If switch_session rejects or times out, this sends new_session inside the existing HAPI session row, so hapi resume <session-id> / web resume can appear successful while the selected conversation context was not restored. That is especially risky after the hub now passes ompSessionFile for exact resume: a missing/moved file should fail visibly instead of starting empty.

Suggested fix:

if (opts.resumeSessionId) {
    await sendOmpRpcAndWait(ompSession, transport, {
        type: 'switch_session',
        sessionPath: opts.resumeSessionId,
    })
} else {
    transport.send({ type: 'new_session' })
}

[github-actions]

Findings

• [Major] OMP resume can switch to the wrong provider when model IDs collide — the startup model reapply only matches modelId, even though this PR persists ompSelectedModel specifically because duplicate model IDs can exist across providers. On resume, the hub/local resume paths pass the legacy session.model string, then switch_session restores the OMP session and get_state may report the correct provider, but this later get_available_models branch can immediately call set_model for the first provider with that modelId. That silently changes the resumed conversation's model/provider. Evidence cli/src/omp/loop.ts:234.
  Suggested fix:

  const providerHint = session.initialModelProvider ?? session.currentProvider
  const match = providerHint
      ? models.find((m) => m.provider === providerHint && m.modelId === session.initialModel)
      : models.find((m) => m.modelId === session.initialModel)

Questions

• None.

Summary

• Review mode: follow-up after new commits
• The previous resume fallback issue is fixed. One remaining OMP resume/model-state issue can still change provider when duplicate modelIds exist.

Testing

• Not run (automation); local bun typecheck could not run here because bun is not installed in this runner image.

HAPI Bot

[github-actions]

[MAJOR] OMP resume can switch to the wrong provider when model IDs collide. This branch only matches the startup request by modelId, but the PR also adds ompSelectedModel because OMP model IDs are not globally unique across providers. After switch_session, get_state can restore the original provider, then this get_available_models handler may immediately choose the first provider with the same modelId and send set_model, silently changing the resumed session's provider.

Suggested fix:

const providerHint = session.initialModelProvider ?? session.currentProvider
const match = providerHint
    ? models.find((m) => m.provider === providerHint && m.modelId === session.initialModel)
    : models.find((m) => m.modelId === session.initialModel)

[github-actions]

Findings

• No issues found.

Questions

• None.

Summary
Review mode: follow-up after new commits
No new high-confidence issues found in the latest full diff. The prior provider-collision finding appears addressed by matching the startup OMP model against currentProvider before falling back to model ID. Residual risk: this review did not execute the external OMP runtime.

Testing

• Not run (automation; review-only, did not execute PR code).

HAPI Bot