You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I opened this as an issue first, but CONTRIBUTING.md says product discussions and feature requests should live in Discussions. Moving the workflow context here so it follows the repository's contribution flow.
Implementation PR: #4046
Original issue, now closed in favor of this discussion: #4045
What I'm trying to do
I use Herdr as the terminal UI for local agent work, and I often have Pi sessions already running there. When I step away from the machine, I want to use Paseo mobile to check and steer that same running Pi session.
The important part is that it stays the same session. I do not want to resume it somewhere else or start a second Paseo-owned Pi process with different context.
How I do it today
Without this integration, the workflow splits in two:
I can keep working in the Herdr terminal, but then Paseo mobile cannot control that running Pi session.
I can start or import a Paseo-managed Pi session, but then I am no longer interacting with the exact terminal-owned session I was already using.
That makes Paseo less useful for the “I am away from the keyboard but still want to respond to the real running agent” case.
Where Paseo gets in the way
Paseo already has the right concepts for agent sessions and mobile control, and Herdr already knows about the live terminal session. The missing piece is that Paseo's Pi provider does not currently treat Herdr-hosted Pi sessions as importable live Pi agents.
The result is not a broken Pi session; it is an ownership gap. The session is alive in Herdr, but Paseo cannot attach to it as the same session.
What the flow would look like if it worked
If Herdr discovery is configured for the built-in Pi provider, Paseo would show eligible Herdr Pi targets in Import session.
Importing one would create a normal provider=pi Paseo agent that is attached to the existing Herdr target instead of starting pi --mode rpc.
From there:
prompts sent from Paseo mobile go through Herdr to the terminal Pi session;
interrupts from Paseo go through Herdr as terminal control keys;
prompts typed directly in the Herdr terminal show up in Paseo after reconciling Pi's native JSONL history.
Shape of the implementation I tried
I implemented this in my fork because I needed the workflow myself.
The shape I chose is intentionally narrow:
this is a Herdr integration for the existing Pi provider, not a new agent provider;
Herdr is not started, stopped, or managed by Paseo;
the imported session stays provider=pi;
Pi's native JSONL history remains the source of truth for attached session history;
attached sessions reconcile completed history entries, while token streaming stays with normal Paseo-managed pi --mode rpc sessions;
reconnect/send refuses to continue if the persisted Herdr target, Pi session, session file, or cwd no longer matches.
Sent a prompt from mobile and confirmed it appeared in the Herdr terminal session.
Typed a prompt directly in the Herdr terminal and confirmed the new history synced back to mobile.
The PR also includes automated tests around Herdr target discovery, attached-session identity, send/interrupt routing, native-history reconciliation, and import behavior.
I have not tested iOS, Android, browser web, macOS desktop, or Windows desktop in this pass. The exercised path is daemon/provider behavior plus the mobile-to-terminal workflow against a Linux Herdr terminal.
What I am looking for
The PR is already open, but I am treating this discussion as the right place for the product/workflow decision.
I would appreciate maintainer feedback on whether this workflow belongs in Paseo, and if so whether the current abstraction is the right fit or should be narrowed/reshaped.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
I opened this as an issue first, but
CONTRIBUTING.mdsays product discussions and feature requests should live in Discussions. Moving the workflow context here so it follows the repository's contribution flow.Implementation PR: #4046
Original issue, now closed in favor of this discussion: #4045
What I'm trying to do
I use Herdr as the terminal UI for local agent work, and I often have Pi sessions already running there. When I step away from the machine, I want to use Paseo mobile to check and steer that same running Pi session.
The important part is that it stays the same session. I do not want to resume it somewhere else or start a second Paseo-owned Pi process with different context.
How I do it today
Without this integration, the workflow splits in two:
That makes Paseo less useful for the “I am away from the keyboard but still want to respond to the real running agent” case.
Where Paseo gets in the way
Paseo already has the right concepts for agent sessions and mobile control, and Herdr already knows about the live terminal session. The missing piece is that Paseo's Pi provider does not currently treat Herdr-hosted Pi sessions as importable live Pi agents.
The result is not a broken Pi session; it is an ownership gap. The session is alive in Herdr, but Paseo cannot attach to it as the same session.
What the flow would look like if it worked
If Herdr discovery is configured for the built-in Pi provider, Paseo would show eligible Herdr Pi targets in Import session.
Importing one would create a normal
provider=piPaseo agent that is attached to the existing Herdr target instead of startingpi --mode rpc.From there:
Shape of the implementation I tried
I implemented this in my fork because I needed the workflow myself.
The shape I chose is intentionally narrow:
provider=pi;pi --mode rpcsessions;cwdno longer matches.Public implementation branch: https://github.com/HackXIt/paseo/tree/feature/herdr-attached-pi-live
What I tested
I tested this in my own workflow on Linux:
The PR also includes automated tests around Herdr target discovery, attached-session identity, send/interrupt routing, native-history reconciliation, and import behavior.
I have not tested iOS, Android, browser web, macOS desktop, or Windows desktop in this pass. The exercised path is daemon/provider behavior plus the mobile-to-terminal workflow against a Linux Herdr terminal.
What I am looking for
The PR is already open, but I am treating this discussion as the right place for the product/workflow decision.
I would appreciate maintainer feedback on whether this workflow belongs in Paseo, and if so whether the current abstraction is the right fit or should be narrowed/reshaped.
All reactions