When delivering cron job output to Telegram, the 'to' field now supports
specifying a topic (forum thread) ID in addition to the chat ID.
Supported formats:
- chatId (plain chat ID or @username)
- chatId:topicId (chat ID with numeric topic ID)
- chatId:topic:topicId (alternative format with explicit marker)
This enables cron jobs to deliver messages to specific forum topics
rather than always going to the main/general topic.
Adds parseTelegramTarget helper function with unit tests.
(cherry picked from commit 24a6595e81d6d1824b2657d714b212c587c3ee8e)
Heartbeat Telegram delivery was failing when the bot token was
configured only via telegram.botToken in config (without TELEGRAM_BOT_TOKEN
environment variable).
Root cause: deliverOutboundPayloads was called without accountId parameter,
so sendMessageTelegram couldn't determine which account to use and couldn't
find the token from config.
Fix: Resolve default Telegram accountId when provider is "telegram" and pass
it to deliverOutboundPayloads. This follows the same pattern used elsewhere in
the codebase (e.g., cron uses resolveTelegramToken).
Changes:
- Added import for resolveDefaultTelegramAccountId
- Added accountId resolution for telegram provider
- Updated deliverOutboundPayloads call to include accountId
Fixes#318
Co-Authored-By: Claude <noreply@anthropic.com>
Fixes parameter mismatch between AI tool schema and internal validation.
The TypeBox schema now uses `jobId` for update/remove/run/runs actions,
matching what users expect based on the returned job objects.
Changes:
- Changed parameter from `id` to `jobId` in TypeBox schema for update/remove/run/runs
- Updated execute function to read `jobId` parameter
- Updated tests to use `jobId` in input parameters
The gateway protocol still uses `id` internally - the tool now maps
`jobId` from the AI to `id` for the gateway call.
Fixes#185
Co-Authored-By: Claude <noreply@anthropic.com>
Heartbeat Telegram delivery was failing when the bot token was
configured only via telegram.botToken in config (without TELEGRAM_BOT_TOKEN
environment variable).
Root cause: deliverOutboundPayloads was called without accountId parameter,
so sendMessageTelegram couldn't determine which account to use and couldn't
find the token from config.
Fix: Resolve default Telegram accountId when provider is "telegram" and pass
it to deliverOutboundPayloads. This follows the same pattern used elsewhere in
the codebase (e.g., cron uses resolveTelegramToken).
Changes:
- Added import for resolveDefaultTelegramAccountId
- Added accountId resolution for telegram provider
- Updated deliverOutboundPayloads call to include accountId
Fixes#318
Co-Authored-By: Claude <noreply@anthropic.com>
Fixes parameter mismatch between AI tool schema and internal validation.
The TypeBox schema now uses `jobId` for update/remove/run/runs actions,
matching what users expect based on the returned job objects.
Changes:
- Changed parameter from `id` to `jobId` in TypeBox schema for update/remove/run/runs
- Updated execute function to read `jobId` parameter
- Updated tests to use `jobId` in input parameters
The gateway protocol still uses `id` internally - the tool now maps
`jobId` from the AI to `id` for the gateway call.
Fixes#185
Co-Authored-By: Claude <noreply@anthropic.com>
The macOS app was crashing in two scenarios:
1. Bundle.module crash (fixes#213): When the first tool event arrived,
ToolDisplayRegistry tried to load config via ClawdbotKitResources.bundle,
which used Bundle.module directly. In packaged apps, Bundle.module
couldn't find the resource bundle at the expected path, causing a
fatal assertion failure after ~40-80 minutes of runtime.
2. dyld crash (fixes#417): Swift 6.2 requires libswiftCompatibilitySpan.dylib
but SwiftPM doesn't bundle it automatically, causing immediate crash on
launch with "Library not loaded" error.
Changes:
- ClawdbotKitResources.swift: Replace direct Bundle.module access with a
safe locator that checks multiple paths and falls back gracefully
- package-mac-app.sh: Copy ClawdbotKit_ClawdbotKit.bundle to Resources
- package-mac-app.sh: Copy libswiftCompatibilitySpan.dylib from Xcode
toolchain to Frameworks
Tested on macOS 26.2 with Swift 6.2 - app launches and runs without crashes.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
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 proper type assertion for ApiClientOptions["fetch"] to resolve
TypeScript compilation errors when passing fetch implementation to
grammY's Bot constructor. This follows the same pattern already used
in bot.ts.
Fixes#465
