When native slash commands are executed in Telegram topics/forums, the
originating topic context was not being preserved. This caused sub-agent
announcements to be delivered to the wrong topic.
Root cause: Native slash command context did not set OriginatingChannel
and OriginatingTo, causing session delivery context to fallback to the
user's personal ID instead of the group ID + topic.
Fix: Added OriginatingChannel and OriginatingTo to native slash command
context, ensuring topic information is preserved for sub-agent announcements.
Related session fields:
- lastThreadId: preserved via MessageThreadId
- lastTo: now correctly set to group ID via OriginatingTo
- deliveryContext: includes threadId for proper routing
This fixes the msteams probe which otherwise incorrectly assumes teams is not working.
The @microsoft/agents-hosting SDK's MsalTokenProvider automatically appends /.default to all scope strings in its token acquisition methods (acquireAccessTokenViaSecret, acquireAccessTokenViaFIC, acquireAccessTokenViaWID, acquireTokenWithCertificate in msalTokenProvider.ts). This is consistent SDK behavior, not a recent change.
The current code is including .default in scope URLs, resulting in invalid double suffixes like https://graph.microsoft.com/.default/.default. I am not sure how the .default postfixed worked in the past for you if I am honest.
This was confirmed to cause Graph API authentication errors. Removing the .default suffix from our scope strings allows the SDK to append it correctly, resolving the issue. I confirmed it manually on my teams setup
Before: we pass .default -> SDK appends -> double .default (broken)
After: we pass base URL -> SDK appends -> single .default (works)
Co-authored-by: Christof Salis <c.salis@vertifymed.com>
Based on actual Flawd deployment experience:
- Proper fly.toml configuration with all required settings
- Step-by-step guide following exe.dev doc format
- Troubleshooting section with common issues and fixes
- Config file creation via SSH
- Cost estimates
In containers, PIDs can be recycled quickly after restarts. When a container
restarts, a different process might get the same PID as the previous gateway,
causing the lock check to incorrectly think the old gateway is still running.
This fix adds isGatewayProcess() which verifies on Linux that the PID actually
belongs to a clawdbot gateway by checking /proc/PID/cmdline. If the cmdline
doesn't contain 'clawdbot' or 'gateway', we assume the lock is stale.
Fixes gateway boot-loop in Docker/Fly.io deployments.
- Add fly.toml configuration for Fly.io deployment
- Add docs/platforms/fly.md with deployment guide
- Uses London (lhr) region by default
- Includes persistent volume for data storage