Prior search
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:
- Large skills invoked via
/skill:<name> can dump the entire skill file into the conversation timeline.
- 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
- Install an OMP skill whose
SKILL.md body is large (hundreds of lines / tens of KB).
- In Paseo, create an agent with provider
omp.
- 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:
- The full skill file body as plain text.
- Then a metadata block such as: /skiabsolute-path-to-SKILL.md
- 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
- In Paseo, use an
omp agent on a task that needs user confirmation (scope, choices, approve/reject, numbered options).
- 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_request → permission_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)
- Skill messages: Render OMP skill activations as a collapsed card (name, path, line count, args); expand body on demand.
- 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.
- 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)
- At gates, reply in plain text with numbered choices.
- Prefer standalone
omp CLI when interactive Ask UI is required.
- For large skills, consider shorter skill bodies or skill metadata that limits auto-injection (skill-side; does not fix timeline rendering alone).
Acceptance criteria
Happy to provide minimal repro steps, logs, or screen recordings on request.
What would solve it
Prior search
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:
- Large skills invoked via
/skill:<name> can dump the entire skill file into the conversation timeline.
- 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
- Install an OMP skill whose
SKILL.md body is large (hundreds of lines / tens of KB).
- In Paseo, create an agent with provider
omp.
- 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:
- The full skill file body as plain text.
- Then a metadata block such as: /skill:absolute-path-to-SKILL.md
- 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
- In Paseo, use an
omp agent on a task that needs user confirmation (scope, choices, approve/reject, numbered options).
- 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_request → permission_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)
- Skill messages: Render OMP skill activations as a collapsed card (name, path, line count, args); expand body on demand.
- 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.
- 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)
- At gates, reply in plain text with numbered choices.
- Prefer standalone
omp CLI when interactive Ask UI is required.
- For large skills, consider shorter skill bodies or skill metadata that limits auto-injection (skill-side; does not fix timeline rendering alone).
Acceptance criteria
Happy to provide minimal repro steps, logs, or screen recordings on request.
Alternatives you considered
No response
Prior search
What's the problem
Summary
When using Paseo with the
ompprovider (oh-my-pi /@oh-my-pi/pi-coding-agentover RPC), two interaction issues show up compared to runningompin the terminal:/skill:<name>can dump the entire skill file into the conversation timeline.Smaller skills and direct CLI usage generally do not show these symptoms as strongly.
Environment
@getpaseo/cli/@getpaseo/server(observed on0.1.100)@oh-my-pi/pi-coding-agent(observed onomp/16.1.16)omp(Paseo spawnsompas an RPC child process)Problem 1 —
/skill:shows full skill body in timelineSteps to reproduce
SKILL.mdbody is large (hundreds of lines / tens of KB).omp./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:
Notes
ompCLI tends to collapse this in the TUI; Paseo appears to render the injected content verbatim.SKILL.md) are much less noticeable.Problem 2 — No structured question UI; conversation appears to stop
Steps to reproduce
ompagent on a task that needs user confirmation (scope, choices, approve/reject, numbered options).ompCLI.Expected
When the agent needs input:
Actual (Paseo)
Actual (standalone
ompCLI)Likely cause
Paseo launches OMP in
--mode rpc. In that mode OMP setshasUI = false, so the built-inasktool is not registered. The model falls back to prose questions in assistant text.Paseo already has server-side plumbing to map OMP
extension_ui_request→permission_requested, but that path is only useful when OMP actually emits UI requests (e.g. viaaskor 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:local:directory under the project cwd iflocal://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
ompCLIompprovider/skill:<small-skill>/skill:<large-skill>Suggested directions (not prescriptive)
rpc-ui) and wire extension UI responses, or provide a headless Ask bridge over existingextension_ui_request/permission_requested.Workarounds (users)
ompCLI when interactive Ask UI is required.Acceptance criteria
/skill:invocations do not flood the timeline with the full skill body by default.Happy to provide minimal repro steps, logs, or screen recordings on request.
What would solve it
Prior search
What's the problem
Summary
When using Paseo with the
ompprovider (oh-my-pi /@oh-my-pi/pi-coding-agentover RPC), two interaction issues show up compared to runningompin the terminal:/skill:<name>can dump the entire skill file into the conversation timeline.Smaller skills and direct CLI usage generally do not show these symptoms as strongly.
Environment
@getpaseo/cli/@getpaseo/server(observed on0.1.100)@oh-my-pi/pi-coding-agent(observed onomp/16.1.16)omp(Paseo spawnsompas an RPC child process)Problem 1 —
/skill:shows full skill body in timelineSteps to reproduce
SKILL.mdbody is large (hundreds of lines / tens of KB).omp./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:
Notes
ompCLI tends to collapse this in the TUI; Paseo appears to render the injected content verbatim.SKILL.md) are much less noticeable.Problem 2 — No structured question UI; conversation appears to stop
Steps to reproduce
ompagent on a task that needs user confirmation (scope, choices, approve/reject, numbered options).ompCLI.Expected
When the agent needs input:
Actual (Paseo)
Actual (standalone
ompCLI)Likely cause
Paseo launches OMP in
--mode rpc. In that mode OMP setshasUI = false, so the built-inasktool is not registered. The model falls back to prose questions in assistant text.Paseo already has server-side plumbing to map OMP
extension_ui_request→permission_requested, but that path is only useful when OMP actually emits UI requests (e.g. viaaskor 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:local:directory under the project cwd iflocal://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
ompCLIompprovider/skill:<small-skill>/skill:<large-skill>Suggested directions (not prescriptive)
rpc-ui) and wire extension UI responses, or provide a headless Ask bridge over existingextension_ui_request/permission_requested.Workarounds (users)
ompCLI when interactive Ask UI is required.Acceptance criteria
/skill:invocations do not flood the timeline with the full skill body by default.Happy to provide minimal repro steps, logs, or screen recordings on request.
Alternatives you considered
No response