mirror of
https://github.com/anthropics/claude-plugins-official.git
synced 2026-08-15 08:33:29 +00:00
1e96c6b0a0
* fix(telegram): honor TELEGRAM_STATE_DIR/CLAUDE_CONFIG_DIR in skills and server The server already reads TELEGRAM_STATE_DIR for multi-bot setups, but the /telegram:access and /telegram:configure skills hardcoded ~/.claude/channels/telegram/ in 11 places. So with a custom state dir the skill writes access.json to the default location while the server reads from the override — pairing and allowlist edits silently don't take effect. Skills now resolve the state dir via shell expansion (TELEGRAM_STATE_DIR → CLAUDE_CONFIG_DIR/channels/telegram → ~/.claude/channels/telegram) before any read/write. Server gets the same CLAUDE_CONFIG_DIR fallback. Also adds Bash(echo)/Bash(chmod) to configure skill's allowed-tools (chmod was already documented but not allowlisted). * fix(telegram): verify stale PID is a server.ts process before SIGTERM PID files race with OS PID recycling. The lockfile from #1349 stored only a PID; after enough churn that PID can be reassigned to anything — including the new launch's own bun-run wrapper. SIGTERMing the wrapper closes our stdin and triggers immediate self-shutdown ('replacing stale poller' then 'shutting down' within seconds — matches #1459 item 3). Now check 'ps -p <pid> -o args=' contains 'server.ts' before killing. execFileSync (no shell); whole block already try/catch so Windows/ps-missing falls through to just overwriting the lockfile. * fix(telegram): drop ppid watchdog check; redirect bun install stdout to stderr Two v0.0.5/0.0.6 regressions causing the plugin to fail at startup: 1. The orphan watchdog's process.ppid !== bootPpid check false-fires when the bun-run/shell wrapper exits or execs during normal startup and we get reparented to init — plugin self-terminates ~5s after launch. Stdin-close alone is the correct signal: the kernel closes the MCP pipe on any CLI death regardless of intermediate wrappers, so the ppid check was both unnecessary and harmful. (#1467; also the actual cause of #1459 item 3 and likely #1425.) 2. 'bun install --no-summary' in the start script writes to stdout, which is the MCP JSON-RPC transport. The harness sees non-JSON bytes during the handshake and drops the connection ('Failed to connect'). Redirect install output to stderr. (#1470; also explains #1425 on Windows.) --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Bryan Thompson <238056179+bryan-anthropic@users.noreply.github.com>
15 lines
307 B
JSON
15 lines
307 B
JSON
{
|
|
"name": "claude-channel-telegram",
|
|
"version": "0.0.1",
|
|
"license": "Apache-2.0",
|
|
"type": "module",
|
|
"bin": "./server.ts",
|
|
"scripts": {
|
|
"start": "bun install --no-summary 1>&2 && bun server.ts"
|
|
},
|
|
"dependencies": {
|
|
"@modelcontextprotocol/sdk": "^1.0.0",
|
|
"grammy": "^1.21.0"
|
|
}
|
|
}
|