Allow the telegram user to reset the context to 0% with slash command `/new`

[kisp]

Currently, the telegram user can invoke /compact. I think it would be great to give the telegram user the possibility to invoke /new as well:

"Simply get rid of all prior context - I do not even want to spend a penny on compacting it."

[casss-dev]

I tried adding this, but it doesn't look like it can be added easily. The ExtensionContext object doesn't have a method to create new sessions, it only exists on the ExtensionCommandContext. I added this as a workaround to mine, but only works if you're using tmux and have a pane open with the current session. Just posting if anyone wants to use it.

		if (lower.startsWith("/new")) {
			if (!ctx.isIdle()) {
				await sendTextReply(firstMessage.chat.id, firstMessage.message_id, "Cannot start a new session while pi is busy. Send \"stop\" first.");
				return;
			}
			if (!ctx.hasUI) {
				await sendTextReply(firstMessage.chat.id, firstMessage.message_id, "Cannot start a new session while pi is not interactive.");
				return;
			}
			await sendTextReply(firstMessage.chat.id, firstMessage.message_id, "New session started");
			await pi.exec("tmux", ["send-keys", "/new", "Enter"])
			return
		}

Then in on session start, you need to reconnect to telegram, start polling again

	pi.on("session_start", async (_event, ctx) => {
                 // ...
		if (config.botToken) {
			await startPolling(ctx);
		}
		// ...
	});

[sebasfavaron]

Implemented this in my fork and tested it end-to-end from Telegram.

Fork: https://github.com/sebasfavaron/pi-telegram
Commit: sebasfavaron/pi-telegram@aa6ae8e

What it does:

• adds native /new as a reserved Telegram command
• exposes it in bot commands/help
• routes it through the bridge instead of sending /new as normal model text
• triggers a fresh pi session from Telegram

One implementation detail: the Telegram polling/update path does not get an ExtensionCommandContext, so calling ctx.newSession() there failed. In this fork I fixed it by intercepting /new in the bridge and queueing the core /new command internally via sendUserMessage("/new", { deliverAs: "followUp" }), which works cleanly in practice.

If useful, I can open a PR against llblab/pi-telegram too.

[stefwoo]

Implemented this in my fork and tested it end-to-end from Telegram.

Fork: https://github.com/sebasfavaron/pi-telegram Commit: sebasfavaron/pi-telegram@aa6ae8e

What it does:

• adds native /new as a reserved Telegram command
• exposes it in bot commands/help
• routes it through the bridge instead of sending /new as normal model text
• triggers a fresh pi session from Telegram

One implementation detail: the Telegram polling/update path does not get an ExtensionCommandContext, so calling ctx.newSession() there failed. In this fork I fixed it by intercepting /new in the bridge and queueing the core /new command internally via sendUserMessage("/new", { deliverAs: "followUp" }), which works cleanly in practice.

If useful, I can open a PR against llblab/pi-telegram too.

This is what I need，I will say thanks to you

[stefwoo]

Implemented this in my fork and tested it end-to-end from Telegram.

Fork: https://github.com/sebasfavaron/pi-telegram Commit: sebasfavaron/pi-telegram@aa6ae8e

What it does:

• adds native /new as a reserved Telegram command
• exposes it in bot commands/help
• routes it through the bridge instead of sending /new as normal model text
• triggers a fresh pi session from Telegram

One implementation detail: the Telegram polling/update path does not get an ExtensionCommandContext, so calling ctx.newSession() there failed. In this fork I fixed it by intercepting /new in the bridge and queueing the core /new command internally via sendUserMessage("/new", { deliverAs: "followUp" }), which works cleanly in practice.

If useful, I can open a PR against llblab/pi-telegram too.

hello sebasfavaron，finally，I found it not working

[llblab]

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.