- Add `label` field to session entries and expose it in `sessions.list`
- Display label column in the web UI sessions table
- Support `label` parameter in `sessions_send` for lookup by label instead of sessionKey
- `sessions.patch`: Accept and store `label` field
- `sessions.list`: Return `label` in session entries
- `sessions_spawn`: Pass label through to registry and announce flow
- `sessions_send`: Accept optional `label` param, lookup session by label if sessionKey not provided
- `agent` method: Accept `label` and `spawnedBy` params (stored in session entry)
- Add `label` column to sessions table in web UI
- Changed session store writes to merge with existing entry (`{ ...existing, ...new }`)
to preserve fields like `label` that might be set separately
We attempted to implement label persistence "properly" by passing the label
through the `agent` call and storing it during session initialization. However,
the auto-reply flow has multiple write points that overwrite the session entry,
and making all of them merge-aware proved unreliable.
The working solution patches the label in the `finally` block of
`runSubagentAnnounceFlow`, after all other session writes complete.
This is a workaround but robust - the patch happens at the very end,
just before potential cleanup.
A future refactor could make session writes consistently merge-based,
which would allow the cleaner approach of setting label at spawn time.
```typescript
// Spawn with label
sessions_spawn({ task: "...", label: "my-worker" })
// Later, find by label
sessions_send({ label: "my-worker", message: "continue..." })
// Or use sessions_list to see labels
sessions_list() // includes label field in response
```
- Integrate dispatchReplyFromConfig() for full agent routing
- Add msteams to TextChunkProvider and OriginatingChannelType
- Add msteams case to route-reply (proactive not yet supported)
- Strip @mention HTML tags from Teams messages
- Fix session key to exclude messageid suffix
- Add typing indicator support
- Add proper logging for debugging
The /status command was showing 'anthropic/claude-sonnet-4-5' even when
using 'google-antigravity/claude-sonnet-4-5' because buildStatusMessage
received only the model name without the provider prefix.
When resolveConfiguredModelRef parsed a model string without a slash,
it fell back to DEFAULT_PROVIDER ('anthropic'), causing the misleading
display.
Fix: Pass the full 'provider/model' string to buildStatusMessage so
the provider is correctly extracted and displayed.
🪿 Investigated and submitted by Keith the Silly Goose
Add signalToolStart to TypingSignaler and call it from onAgentEvent
when tools begin executing. This keeps the typing indicator visible
during long-running tool operations.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Previously, startTypingLoop would return early if the typing timer was
already running, which meant the TTL would never get refreshed during
long tool executions. This caused the typing indicator to stop after
2 minutes even if tools were still running.
Now we refresh the TTL at the start of startTypingLoop, before the
early-return checks. This keeps typing alive during long operations.
- Default: sendAudio (file with metadata) - preserves old behavior
- Opt-in: [[audio_as_voice]] tag for voice bubble
This is non-breaking - existing integrations keep working.
Allow agents to specify audio mode via inline tag:
- Default: voice bubble (sendVoice)
- [[audio_as_file]]: audio file with metadata (sendAudio)
The tag is stripped from the final message text.
Example agent response:
Here's a podcast episode! [[audio_as_file]]
MEDIA:https://example.com/episode.mp3
- Add audioAsVoice option to ReplyPayload type
- Update bot.ts to use sendVoice by default for audio (voice bubble)
- When audioAsVoice is false, use sendAudio (file with metadata)
This allows agents to control voice vs file mode via ReplyPayload.
Add topic-specific session file isolation to fix root cause of Gemini turn validation errors.
Each Telegram topic now maintains its own conversation history file, eliminating race
conditions and message corruption during concurrent topic processing.
Changes:
1. Enhanced resolveSessionTranscriptPath() to support optional topicId parameter
- Topic ID (Telegram messageThreadId) now incorporated into session filename
- Format: sessionId.jsonl (direct chats) vs sessionId-topic-{topicId}.jsonl (topics)
- Backward compatible: topicId is optional
2. Updated reply.ts to pass MessageThreadId to session file resolution
- ctx.MessageThreadId now flows through to resolveSessionTranscriptPath()
- Automatically provides topic context for each incoming message
3. Automatic propagation through entire system
- sessionFile parameter automatically carries topic-specific path through:
- FollowupRun object (queued runs)
- runEmbeddedPiAgent() calls
- compactEmbeddedPiSession() calls
- SessionManager lifecycle (load, read, write operations)
Benefits:
✓ Complete elimination of shared .jsonl race conditions
✓ Each topic's conversation history independently cached
✓ SessionManager instances operate on isolated files
✓ No concurrent mutations of the same message history
✓ Maintains full Phase 1 turn validation as safety layer
Testing:
✓ Build succeeds with no TypeScript errors
✓ Backward compatible with non-topic sessions (direct messages)
✓ Topic ID properly extracted from Telegram messageThreadId
Expected impact:
- Gemini "function call turn" errors eliminated (root cause fixed)
- Message history corruption prevented across all topics
- Improved stability in multi-topic scenarios
- Each topic maintains independent conversation state
This completes the two-phase fix:
- Phase 1 (previous): Turn validation to suppress errors
- Phase 2 (current): Topic isolation to fix root cause
🤖 Generated with Claude Code
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
When queued messages come from different providers (Slack + Telegram),
process them individually instead of collecting into a single prompt.
This ensures each reply routes back to its originating provider.
- Add hasCrossProviderItems() to detect multi-provider queues
- Skip collect mode when cross-provider detected
- Preserve originatingChannel/originatingTo when collecting same-provider
When OriginatingChannel matches Surface (same provider), use normal
dispatcher. Only route via routeReply() when they differ, ensuring
cross-provider messages (e.g., Telegram queued while Slack active)
get routed back to their origin.
Implement reply routing based on OriginatingChannel/OriginatingTo fields.
This ensures replies go back to the provider where the message originated
instead of using the session's lastChannel.
Changes:
- Add OriginatingChannel/OriginatingTo fields to MsgContext (templating.ts)
- Add originatingChannel/originatingTo fields to FollowupRun (queue.ts)
- Create route-reply.ts with provider-agnostic router
- Update all providers (Telegram, Slack, Discord, Signal, iMessage)
to pass originating channel info
- Update reply.ts to pass originating channel to followupRun
- Update followup-runner.ts to use route-reply for originating channels
This addresses the issue where messages from one provider (e.g., Slack)
would receive replies on a different provider (e.g., Telegram) because
the queue used the last active dispatcher instead of the originating one.
- Added `isError` property to `EmbeddedPiRunResult` and reply items to indicate error states.
- Updated error handling in `runReplyAgent` to provide more informative messages for specific socket connection errors.
