Support starting a new Pi session from Telegram

[tlerbao]

Feature request

It would be useful if pi-telegram provided a Telegram-native way to start a fresh Pi session, similar to the /new command available in the local Pi TUI.

Current behavior

In a local Pi TUI session, users can run:

/new

to start a new session.

In Telegram, however, /new is not exposed as a bot command. This is understandable because pi-telegram intentionally does not forward arbitrary Pi slash commands or emulate a remote TTY.

Use case

For a long-running NAS/server deployment, a dedicated Pi process is kept alive for Telegram via /telegram-connect. The user may also run separate local Pi sessions over SSH.

In this setup, Telegram needs a clean way to reset/start a new conversation without SSHing into the host or restarting the whole service manually.

Example deployment:

systemd/tmux
  └─ pi
      └─ /telegram-connect

separate SSH sessions may run independent `pi` processes without `/telegram-connect`

Desired behavior

Provide a Telegram-native command or menu action, for example:

/new

or

/new_session

that starts a fresh Pi session for the Telegram-connected runtime.

Ideally this would use an official Pi API for session replacement rather than raw TTY injection. If Pi does not currently expose that API, even a documented recommended pattern would help.

Possible design constraints

• Should preserve the Telegram polling lock/ownership.
• Should avoid forwarding arbitrary slash commands from Telegram to the Pi TUI.
• Should not conflict with separate local Pi sessions.
• Should probably ask for confirmation if there is active work or queued Telegram prompts.
• Could be exposed in /start menu as “New session”.

Why this matters

For always-on Telegram deployments, /compact is helpful, but it is not equivalent to starting a completely fresh conversation. Users sometimes need a clean context from Telegram without restarting the daemon/service manually.

[llblab]

Thanks for the suggestion — this is a good fit for always-on Telegram deployments.

This is already tracked in the project backlog. Pi's session-replacement API has evolved since the original constraint was written, so this now looks implementable through the official session API rather than unsafe TTY/subprocess workarounds.

Work for the next release is happening on dev, and I plan to include a Telegram-native new-session action there if the integration validates cleanly.

[llblab]

Update after implementation review:

This is currently blocked for a true same-thread /new in pi-telegram alone.

Blockers:

• Pi exposes ctx.newSession() only on ExtensionCommandContext.
• Telegram update handlers run with ordinary ExtensionContext, not command context.
• pi.exec is a shell executor, not a Pi slash-command dispatcher, so it is not a valid bridge to the built-in /new command.
• Storing an old ExtensionCommandContext and calling it later would risk stale-context/session-replacement bugs.
• TUI input injection, spawning a shadow pi subprocess, or mutating session files directly would bypass Pi runtime invariants and should not be used.

The clean unblocker is a small Pi core/SDK API such as pi.newSession(...) or pi.requestSessionReplacement(...), callable from trusted extension runtime code and internally using the same AgentSessionRuntime.newSession() path as the TUI. Upstream request: earendil-works/pi#5952

There is a separate Threaded Mode-only path that remains possible without Pi core changes: creating a new Telegram topic can create/bind a separate live Pi instance. That is a "new thread / new instance" feature, not a same-thread session reset, so it should be tracked and implemented separately from Telegram /new.

[tlerbao]

Thanks for the detailed implementation review. I want to confirm my understanding.

I previously used Hermes Agent, which works as a long-running gateway. Because the gateway process stays alive, Telegram can start a fresh conversation with /new at any time.

Based on your reply, is my understanding correct that Pi currently cannot support the same behavior from Telegram, and that a true same-thread /new has to wait for a new Pi core/SDK API such as pi.newSession(...) or pi.requestSessionReplacement(...)?

My current setup is a long-running Pi process kept alive in tmux on the host machine, so I can message it from Telegram anytime, similar to how I used Hermes.

In the current Pi/Telegram model, if /new is not available and the only option is /compact, is there a risk that the session context will keep growing over time and eventually degrade the assistant's behavior? Or is /compact expected to be sufficient for long-running always-on Telegram usage?

[llblab]

Yes, that understanding is correct, with one important architectural distinction.

There are two possible models here:

1. A separate Telegram gateway process that sits above the agent runtime and launches/manages Pi agent instances itself. In that model the gateway can juggle instances, sessions, and process lifecycles because it owns the layer above the agents.

2. A Pi extension, which is what pi-telegram is. In this model the Telegram bridge runs inside an existing Pi runtime and must play by the public API that Pi exposes to extensions.

pi-telegram is intentionally in the second category. It does not own Pi process/session orchestration directly; it extends the current Pi session through the extension API.

So yes: a true same-thread Telegram /new currently has to wait for a Pi core/SDK API such as pi.newSession(...) or pi.requestSessionReplacement(...). The local TUI has a safe session replacement path, but an ordinary extension update handler currently does not have that same safe primitive. I do not want to fake it with TUI injection, a shadow subprocess, stale command contexts, or direct session-file mutation.

For long-running usage, /compact is the current safe baseline. It is meant to let a session continue after the context gets large by compressing prior conversation state into a summary. In that sense, you can keep compacting and continue working for a long time; manually or automatically, the model context should not just grow as raw history forever.

But /compact is not identical to /new. Compaction preserves continuity by design. It is more like tightening a long thread of work into a smaller knot and continuing from that knot. The quality depends on the compaction prompt, model, and what was in the session. It is usually good enough for continuity and for moving on after context pressure, but it is not a guaranteed clean slate.

So the current practical answer is:

• /compact is the minimal safe always-on option today.
• It should be sufficient for many long-running Telegram workflows.
• If you need a true clean conversation in the same Telegram thread, that is exactly the missing upstream API tracked here: ExtensionAPI should expose a safe session replacement API for trusted async UI extensions earendil-works/pi#5952
• A separate future Threaded Mode feature could also create a new Telegram topic / new Pi instance, but that is a different model from same-thread /new.

[tlerbao]

Thanks, that distinction makes sense.

Do you know whether Pi upstream already has a plan to expose a session-replacement API for trusted extensions, such as pi.newSession(...) or pi.requestSessionReplacement(...)?

If this is not already on the upstream roadmap, would it be helpful for me to open or support a dedicated upstream issue/feature request describing the Telegram always-on use case and why /compact is not a full replacement for a clean /new session?

[llblab]

I do not know of a confirmed upstream roadmap for this.

I only investigated this specific blocker from the pi-telegram side and concluded that the safe fix would need a Pi core/SDK API exposed to trusted extensions. I opened the upstream request here:

earendil-works/pi#5952

Since this is my first issue in the upstream Pi repository, it was auto-closed by their new-contributor gate. I would not read that as a technical decision either way.

So the honest answer is: I do not know more than you about whether or when upstream will implement it. The request exists, but the design decision and priority are up to the Pi maintainers.

[danielytics]

I would also like this feature. Hopefully the upstream request is accepted.