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.
- Integrate message_sending hook into Telegram delivery path
- Send text first, then audio as voice message after
- Add /tts_provider command to switch between OpenAI and ElevenLabs
- Implement automatic fallback when primary provider fails
- Use gpt-4o-mini-tts as default OpenAI model
- Add hook integration to route-reply.ts for other channels
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Address reviewer feedback: slash commands now use the same
hasExplicitConfig check as regular messages, so unlisted
channels are allowed under groupPolicy: "open" for both
message handling and slash commands.
## Summary
Fix Slack `groupPolicy: "open"` to allow unlisted channels even when `channels.slack.channels` contains custom entries.
## Problem
When `groupPolicy` is set to `"open"`, the bot should respond in **any channel** it's invited to. However, if `channels.slack.channels` contains *any* entries—even just one channel with a custom system prompt—the open policy is ignored. Only explicitly listed channels receive responses; all others get an ephemeral "This channel is not allowed" error.
### Example config
```json
{
"channels": {
"slack": {
"groupPolicy": "open",
"channels": {
"C0123456789": { "systemPrompt": "Custom prompt for this channel" }
}
}
}
}
```
With this config, the bot only responds in `C0123456789`. Messages in any other channel are blocked—even though the policy is `"open"`.
## Root Cause
In `src/slack/monitor/context.ts`, `isChannelAllowed()` has two sequential checks:
1. `isSlackChannelAllowedByPolicy()` — correctly returns `true` for open policy
2. A secondary `!channelAllowed` check — was blocking channels when `resolveSlackChannelConfig()` returned `{ allowed: false }` for unlisted channels
The second check conflated "channel not in config" with "channel explicitly denied."
## Fix
Use `matchSource` to distinguish explicit denial from absence of config:
```ts
const hasExplicitConfig = Boolean(channelConfig?.matchSource);
if (!channelAllowed && (params.groupPolicy !== "open" || hasExplicitConfig)) {
return false;
}
```
When `matchSource` is undefined, the channel has no explicit config entry and should be allowed under open policy.
## Behavior After Fix
| Scenario | Result |
|----------|--------|
| `groupPolicy: "open"`, channel unlisted | ✅ Allowed |
| `groupPolicy: "open"`, channel explicitly denied (`allow: false`) | ❌ Blocked |
| `groupPolicy: "open"`, channel with custom config | ✅ Allowed |
| `groupPolicy: "allowlist"`, channel unlisted | ❌ Blocked |
## Test Plan
- [x] Open policy + unlisted channel → allowed
- [x] Open policy + explicitly denied channel → blocked
- [x] Allowlist policy + unlisted channel → blocked
- [x] Allowlist policy + listed channel → allowed
Added a dedicated Anthropic payload logger that writes exact request
JSON (as sent) plus per‑run usage stats (input/output/cache read/write)
to a
standalone JSONL file, gated by an env flag.
Changes
- New logger: src/agents/anthropic-payload-log.ts (writes
logs/anthropic-payload.jsonl under the state dir, optional override via
env).
- Hooked into embedded runs to wrap the stream function and record
usage: src/agents/pi-embedded-runner/run/attempt.ts.
How to enable
- CLAWDBOT_ANTHROPIC_PAYLOAD_LOG=1
- Optional:
CLAWDBOT_ANTHROPIC_PAYLOAD_LOG_FILE=/path/to/anthropic-payload.jsonl
What you’ll get (JSONL)
- stage: "request" with payload (exact Anthropic params) +
payloadDigest
- stage: "usage" with usage
(input/output/cacheRead/cacheWrite/totalTokens/etc.)
Notes
- Usage is taken from the last assistant message in the run; if the
run fails before usage is present, you’ll only see an error field.
Files touched
- src/agents/anthropic-payload-log.ts
- src/agents/pi-embedded-runner/run/attempt.ts
Tests not run.
- Add registry lock during command execution to prevent race conditions
- Add input sanitization for command arguments (defense in depth)
- Validate handler is a function during registration
- Remove redundant case-insensitive regex flag
- Add success logging for command execution
- Simplify handler return type (always returns result now)
- Remove dead code branch in commands-plugin.ts
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add clearPluginCommands() call in loadClawdbotPlugins() to ensure
previously registered commands are cleaned up before reloading plugins.
This prevents command conflicts during hot-reload scenarios.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Blockers fixed:
- Fix documentation: requireAuth defaults to true (not false)
- Add command name validation (must start with letter, alphanumeric only)
- Add reserved commands list to prevent shadowing built-in commands
- Emit diagnostic errors for invalid/duplicate command registration
Other improvements:
- Return user-friendly message for unauthorized commands (instead of silence)
- Sanitize error messages to avoid leaking internal details
- Document acceptsArgs behavior when arguments are provided
- Add notes about reserved commands and validation rules to docs
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This adds a new `api.registerCommand()` method to the plugin API, allowing
plugins to register slash commands that execute without invoking the AI agent.
Features:
- Plugin commands are processed before built-in commands and the agent
- Commands can optionally require authorization
- Commands can accept arguments
- Async handlers are supported
Use case: plugins can implement toggle commands (like /tts_on, /tts_off)
that respond immediately without consuming LLM API calls.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
