Sessions started with --channels write no transcript to ~/.claude/projects/

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

A session launched with --channels plugin:telegram@claude-plugins-official
runs normally — it receives messages, answers them, and the user sees the
replies in Telegram — but it never writes a .jsonl transcript to
~/.claude/projects/<project-slug>/. No error is printed, no file is created,
and an existing transcript being resumed stops growing.

The same binary, in the same working directory, with the channel flag
removed, writes the transcript normally. That is the only difference between
the passing and failing runs.

Consequence: --continue and --resume have nothing to resume. Every restart
of the agent loses the conversation, silently. Nothing surfaces the loss —
the assistant keeps answering, so from the outside it looks healthy.

Environment

• Claude Code 2.1.250, installed globally via npm

(%APPDATA%\npm\node_modules\@anthropic-ai\claude-code\bin\claude.exe)

• Telegram plugin 0.0.7 (claude-plugins-official)
• Windows 11 Pro 26200, Node v24.18.1
• A separate native install (%APPDATA%\Claude\claude-code\2.1.247\) exists on

the same machine and is unaffected — it is used by other sessions, which do
write transcripts.

Isolation

Six sessions on the same machine, same day, same project directory where noted.
The only variable that tracks the outcome is the channel flag.

| session | --channels | transcript written |
|---|---|---|
| -p in a neutral folder | no | yes (34 KB) |
| -p in the agent's folder | no | yes (42 KB) |
| --channels, brand-new conversation | yes | no |
| --channels, brand-new conversation (2nd try) | yes | no |
| --resume <id> --channels, three separate runs | yes | no |
| unrelated interactive session, same machine | no | yes |

Ruled out by measurement, not by guess:

• Transcript size — the resumed file is 36 MB, but brand-new conversations

(zero bytes) fail identically.

• --resume — the two brand-new sessions do not use it and fail identically.
• The working directory — the same binary writes in that exact directory

once the channel flag is dropped.

• Version — the package was reinstalled (incoherent 2.1.220 manifest with a

newer binary → clean 2.1.250) and the symptom survived unchanged.

Reproduction

1. Start a session with the Telegram channel attached:

claude --channels plugin:telegram@claude-plugins-official

1. Send it a message from Telegram and let it answer. Confirm the answer

arrives.

1. Look in ~/.claude/projects/<slug-of-cwd>/ — no new .jsonl, and if the

session was resumed, the existing file's byte count is unchanged.

1. Repeat without --channels (a plain claude -p "reply only: OK" in the same

directory is enough) — the .jsonl appears.

Compare by byte count, not modification time: the launcher touches the
mtime of the resumed file when opening it, which looks like a write and is not.

Timeline that may or may not be relevant

On this machine the last successfully recorded turn was at 12:38 local. Every
session started after that wrote nothing. Roughly two hours earlier the npm
package's claude.exe had been replaced on disk (the package.json still read
2.1.220 while the binary was newer). The window that was already running —
loaded before that swap — kept recording until it was closed.

That correlation is suggestive but unproven: the previous binary was already
gone by the time the problem was noticed, so its version was never measured and
there is nothing left to compare against.

What would help

Even without a fix, an error on the failing path would have saved a day of
guessing. The failure mode is complete silence: the assistant answers, the
process is healthy, the queue is empty, and the only visible symptom is a file
that quietly stops growing.

What Should Happen?

The session should append its turns to the .jsonl transcript in ~/.claude/projects/<project-slug>/, exactly as the same binary does when it runs without --channels. Restarting the agent with --continue or --resume should then recover the conversation.

At minimum, if the transcript cannot be written, the failure should surface as an error. Today it is completely silent: the assistant keeps answering over the channel, the process is healthy, and the only symptom is a file that quietly stops growing.

Error Messages/Logs

None. No error, warning, or log line is produced on the failing path — that is a central part of the report.

Steps to Reproduce

1. Start a session with a channel attached:

claude --channels plugin:telegram@claude-plugins-official

1. Send it a message from Telegram and let it answer. Confirm the reply arrives.

1. Look in ~/.claude/projects/<slug-of-cwd>/ — no new .jsonl file appears. If the session was started with --resume, the existing file's byte count does not change.

1. Repeat in the same directory without the channel flag:

claude -p "reply only: OK"

The .jsonl appears normally.

Compare by BYTE COUNT, not modification time: opening a resumed transcript touches its mtime without writing anything, which looks like a write and is not.

Tested on this machine with brand-new conversations and with --resume, and with the npm package reinstalled from an incoherent 2.1.220 manifest to a clean 2.1.250 — the behaviour is identical in all of them. The only variable that changes the outcome is the presence of --channels.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.250 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_