Skip to content

feat: [omp provider] Large skills expand full body in timeline; structured user questions unavailable in RPC mode #1726

Description

@ClarePhang

Prior search

  • I searched existing issues and discussions, and this isn't already proposed.

What's the problem

Summary

When using Paseo with the omp provider (oh-my-pi / @oh-my-pi/pi-coding-agent over RPC), two interaction issues show up compared to running omp in the terminal:

  1. Large skills invoked via /skill:<name> can dump the entire skill file into the conversation timeline.
  2. Structured user questions (options, confirmations, gates) do not appear; the agent often asks in plain text and the turn ends, so the user must send another message to continue.

Smaller skills and direct CLI usage generally do not show these symptoms as strongly.


Environment

  • Paseo: @getpaseo/cli / @getpaseo/server (observed on 0.1.100)
  • OMP: @oh-my-pi/pi-coding-agent (observed on omp/16.1.16)
  • Provider: omp (Paseo spawns omp as an RPC child process)
  • OS: Linux

Problem 1 — /skill: shows full skill body in timeline

Steps to reproduce

  1. Install an OMP skill whose SKILL.md body is large (hundreds of lines / tens of KB).
  2. In Paseo, create an agent with provider omp.
  3. Invoke the skill: /skill:<name> <args>.

Expected

Skill activation is shown in a compact form (name, path, args). The full skill text should not dominate the timeline by default.

Actual

The timeline shows:

  1. The full skill file body as plain text.
  2. Then a metadata block such as: /skiabsolute-path-to-SKILL.md
  3. Execution continues only after that wall of text.

Notes

  • This does not look like the skill being loaded twice; OMP injects the skill body into the prompt message by design.
  • Standalone omp CLI tends to collapse this in the TUI; Paseo appears to render the injected content verbatim.
  • Small skills (short SKILL.md) are much less noticeable.
  • Severity scales with skill file size, not with a specific skill name.

Problem 2 — No structured question UI; conversation appears to stop

Steps to reproduce

  1. In Paseo, use an omp agent on a task that needs user confirmation (scope, choices, approve/reject, numbered options).
  2. Compare the same flow in standalone omp CLI.

Expected

When the agent needs input:

  • Show an interactive question UI (options, multi-select, confirm, freeform where supported).
  • After the user answers, continue the same turn / workflow without requiring a new user message just to “unstick” the session.

Actual (Paseo)

  • The agent writes plain-text questions in the assistant message.
  • No structured question card is shown.
  • The turn ends; the user must type a new message to proceed.

Actual (standalone omp CLI)

  • Structured Ask UI works as expected.

Likely cause

Paseo launches OMP in --mode rpc. In that mode OMP sets hasUI = false, so the built-in ask tool is not registered. The model falls back to prose questions in assistant text.

Paseo already has server-side plumbing to map OMP extension_ui_requestpermission_requested, but that path is only useful when OMP actually emits UI requests (e.g. via ask or extension UI). In default RPC mode, those requests often never happen.


Problem 3 — Subagent / internal URL artifacts (secondary)

When OMP runs subagents or uses internal local:// handoffs, users may see:

  • Session-scoped artifacts under a temp directory (expected).
  • Occasionally a literal local: directory under the project cwd if local:// paths are resolved incorrectly.

This is mostly an OMP/runtime concern, but Paseo users running multi-agent workflows hit it more often. Documentation on expected locations and cleanup would help.


Reproduction matrix

Scenario Standalone omp CLI Paseo + omp provider
/skill:<small-skill> Usually fine Usually fine
/skill:<large-skill> Compact / folded UI Full body in timeline
Agent asks for user choice Structured Ask UI Plain text; turn ends

Suggested directions (not prescriptive)

  1. Skill messages: Render OMP skill activations as a collapsed card (name, path, line count, args); expand body on demand.
  2. Structured questions: Either launch OMP with a UI-capable RPC mode (e.g. rpc-ui) and wire extension UI responses, or provide a headless Ask bridge over existing extension_ui_request / permission_requested.
  3. Degraded mode: If structured UI is unavailable, show a clear notice and keep the session in a “waiting for answer” state instead of ending the turn silently.

Workarounds (users)

  1. At gates, reply in plain text with numbered choices.
  2. Prefer standalone omp CLI when interactive Ask UI is required.
  3. For large skills, consider shorter skill bodies or skill metadata that limits auto-injection (skill-side; does not fix timeline rendering alone).

Acceptance criteria

  • Large /skill: invocations do not flood the timeline with the full skill body by default.
  • User questions that work in OMP CLI also work in Paseo (or parity limits are documented).
  • After answering a gate question, the agent resumes without an extra manual “nudge” message.

Happy to provide minimal repro steps, logs, or screen recordings on request.

What would solve it

Prior search

  • I searched existing issues and discussions, and this isn't already proposed.

What's the problem

Summary

When using Paseo with the omp provider (oh-my-pi / @oh-my-pi/pi-coding-agent over RPC), two interaction issues show up compared to running omp in the terminal:

  1. Large skills invoked via /skill:<name> can dump the entire skill file into the conversation timeline.
  2. Structured user questions (options, confirmations, gates) do not appear; the agent often asks in plain text and the turn ends, so the user must send another message to continue.

Smaller skills and direct CLI usage generally do not show these symptoms as strongly.


Environment

  • Paseo: @getpaseo/cli / @getpaseo/server (observed on 0.1.100)
  • OMP: @oh-my-pi/pi-coding-agent (observed on omp/16.1.16)
  • Provider: omp (Paseo spawns omp as an RPC child process)
  • OS: Linux

Problem 1 — /skill: shows full skill body in timeline

Steps to reproduce

  1. Install an OMP skill whose SKILL.md body is large (hundreds of lines / tens of KB).
  2. In Paseo, create an agent with provider omp.
  3. Invoke the skill: /skill:<name> <args>.

Expected

Skill activation is shown in a compact form (name, path, args). The full skill text should not dominate the timeline by default.

Actual

The timeline shows:

  1. The full skill file body as plain text.
  2. Then a metadata block such as: /skill:absolute-path-to-SKILL.md
  3. Execution continues only after that wall of text.

Notes

  • This does not look like the skill being loaded twice; OMP injects the skill body into the prompt message by design.
  • Standalone omp CLI tends to collapse this in the TUI; Paseo appears to render the injected content verbatim.
  • Small skills (short SKILL.md) are much less noticeable.
  • Severity scales with skill file size, not with a specific skill name.

Problem 2 — No structured question UI; conversation appears to stop

Steps to reproduce

  1. In Paseo, use an omp agent on a task that needs user confirmation (scope, choices, approve/reject, numbered options).
  2. Compare the same flow in standalone omp CLI.

Expected

When the agent needs input:

  • Show an interactive question UI (options, multi-select, confirm, freeform where supported).
  • After the user answers, continue the same turn / workflow without requiring a new user message just to “unstick” the session.

Actual (Paseo)

  • The agent writes plain-text questions in the assistant message.
  • No structured question card is shown.
  • The turn ends; the user must type a new message to proceed.

Actual (standalone omp CLI)

  • Structured Ask UI works as expected.

Likely cause

Paseo launches OMP in --mode rpc. In that mode OMP sets hasUI = false, so the built-in ask tool is not registered. The model falls back to prose questions in assistant text.

Paseo already has server-side plumbing to map OMP extension_ui_requestpermission_requested, but that path is only useful when OMP actually emits UI requests (e.g. via ask or extension UI). In default RPC mode, those requests often never happen.


Problem 3 — Subagent / internal URL artifacts (secondary)

When OMP runs subagents or uses internal local:// handoffs, users may see:

  • Session-scoped artifacts under a temp directory (expected).
  • Occasionally a literal local: directory under the project cwd if local:// paths are resolved incorrectly.

This is mostly an OMP/runtime concern, but Paseo users running multi-agent workflows hit it more often. Documentation on expected locations and cleanup would help.


Reproduction matrix

Scenario Standalone omp CLI Paseo + omp provider
/skill:<small-skill> Usually fine Usually fine
/skill:<large-skill> Compact / folded UI Full body in timeline
Agent asks for user choice Structured Ask UI Plain text; turn ends

Suggested directions (not prescriptive)

  1. Skill messages: Render OMP skill activations as a collapsed card (name, path, line count, args); expand body on demand.
  2. Structured questions: Either launch OMP with a UI-capable RPC mode (e.g. rpc-ui) and wire extension UI responses, or provide a headless Ask bridge over existing extension_ui_request / permission_requested.
  3. Degraded mode: If structured UI is unavailable, show a clear notice and keep the session in a “waiting for answer” state instead of ending the turn silently.

Workarounds (users)

  1. At gates, reply in plain text with numbered choices.
  2. Prefer standalone omp CLI when interactive Ask UI is required.
  3. For large skills, consider shorter skill bodies or skill metadata that limits auto-injection (skill-side; does not fix timeline rendering alone).

Acceptance criteria

  • Large /skill: invocations do not flood the timeline with the full skill body by default.
  • User questions that work in OMP CLI also work in Paseo (or parity limits are documented).
  • After answering a gate question, the agent resumes without an extra manual “nudge” message.

Happy to provide minimal repro steps, logs, or screen recordings on request.

Alternatives you considered

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions