### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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? I constantly keep getting errors like these: API Error: Connection closed mid-response. The response above may be incomplete. API Error: Stream idle t

[BUG] Consantly getting: API Error: Stream idle timeout - no chunks received

Status Closed — duplicate

Reported on v2.1.215

Maintainer reply None cached

Activity 2 comments · opened Jul 20, 2026 · closed Aug 19, 2026

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?

I constantly keep getting errors like these:
API Error: Connection closed mid-response. The response above may be incomplete.
API Error: Stream idle timeout - no chunks received
Waiting for API Response - will retry in 1m 32s - check your network.

I'm trying to get it to write a fairly simple Python program that is probably less than 100 lines of code.
Below is my conversation with Claude Desktop which works fine, asking it how to fix it.

I have turned off firewalls and Tailscale. This has been happening now for weeks.
Sometime when I retry it will work, but it now seems almost unusable.

I'm running from command prompt like this:
claude --dangerously-skip-permissions --verbose

I was running under Warp, but now same issues under regular Windows command windows (in Admin mode).

I tried with and without the /plan command.
I have tried with Sonnet and Opus.

/plan I copied GetChatId.py to MonitorTelegramGroups.py, and I added this to the config.json: "TELEGRAM_GROUPS_TO_MONITOR": "Seminar Group,-1003297259178" That parm will be a comma separate list of groups and chatids, example "Group1, Chatid1, Group2, Chatid2". I want you to save in a little text file that date/time this program last ran, and then get all the new posts to that telegram group since that date/time, write to console, and then udpate the date/time file.

⎿ Enabled plan mode

I'll research the existing code before planning. Let me look at the relevant files.

● Read(C:\GitHub\DomainManagementPython\ClaudeConnectors\Telegram\MonitorTelegramGroups.py)
Read 79 lines

● Read(C:\GitHub\DomainManagementPython\ClaudeConnectors\Telegram\GetChatId.py)
Read 79 lines

● Read(C:\GitHub\DomainManagementPython\ClaudeConnectors\Telegram\requirements.txt)
Read 3 lines

Let me look at the config and check for existing patterns for state/timestamp files.

● Bash(grep -n "TELEGRAM" config.json)
100:, "TELEGRAM_API_ID": "xxxx10100",
101: "TELEGRAM_API_HASH": "xxxxxxxxxxxxxxxxxxxxxxxxxxxx",
102: "TELEGRAM_PHONE": "xxxxxxxxxx",
103: "TELEGRAM_TEST_SERVER": "149.154.167.40:443",
104: "TELEGRAM_PROD_SERVER": "149.154.167.50:443",
105: "TELEGRAM_GROUPS_TO_MONITOR": "Seminar Group,-1003297259178"

● Bash(cd /c/GitHub/DomainManagementPython/ClaudeConnectors/Telegram && ls -la)
total 77
drwxr-xr-x 1 nwalt 197610 0 Jul 19 22:07 ./
drwxr-xr-x 1 nwalt 197610 0 Jul 19 19:04 ../
-rw-r--r-- 1 nwalt 197610 2630 Jul 19 22:03 GetChatId.py
-rw-r--r-- 1 nwalt 197610 2630 Jul 19 22:03 MonitorTelegramGroups.py
drwxr-xr-x 1 nwalt 197610 0 Jul 19 20:02 __pycache__/
-rw-r--r-- 1 nwalt 197610 38 Jul 19 19:30 requirements.txt
-rw-r--r-- 1 nwalt 197610 57344 Jul 19 22:04 telegram_session.session

✻ Waiting for API response · will retry in 1m 59s · check your network

--------------------
Below is my conversation with Claude Desktop to try to fix it...

Claude finished the response
When running Claude Code from windows command prompt, how do I get it to show me more status and progress while it is running. Sometimes I think it should only run 1 or 2 minutes, and it runs 5 or 10 minutes, and I have no idea what it is really doing.

Synthesized visibility features and keyboard shortcuts for monitoring progress
Synthesized visibility features and keyboard shortcuts for monitoring progress
Good news — Claude Code isn't actually a black box while it's running, it's just collapsed by default. A few ways to get more visibility, especially useful on Windows cmd:

See what it's doing live (no flag needed)

In interactive mode, Claude Code already prints each action it takes — which file it's reading, which command it's running, which edit it's making — just abbreviated to one line each. If a step is collapsed, you can usually expand it in the transcript to see full output.

--verbose flag

Run it as:

claude --verbose
This shows the full turn-by-turn detail — every tool call with its parameters and results, not just a one-line summary. It's the most direct fix for "what is it actually doing right now."

Turn on a status line

Inside a session, type:

/statusline
and describe what you want shown — e.g. "show model name, context percentage with a progress bar." Claude Code will generate a script for it and it'll persist at the bottom of your terminal, so you can see context usage and current model at a glance (handy for spotting when it's about to auto-compact, which is a common cause of runs feeling longer than expected).

Check the todo/plan list

For multi-step tasks, Claude Code keeps a running todo list of what it's planned out and checks items off as it goes — worth glancing at if a run seems to be taking longer than expected, since it tells you how many steps are left rather than just "still working."

Piping to a file for later review

If you want a full log to scroll back through after a long run:

claude --verbose --output-format stream-json -p "your task" > run-log.json
(This is more for non-interactive/scripted runs though — for normal interactive work, --verbose plus the built-in transcript is usually enough.)

One likely reason your runs stretch to 5–10 minutes: Claude Code often does more exploration (reading related files, checking for existing patterns, running tests) than a quick glance at the prompt suggests it needs. The --verbose flag is the fastest way to confirm whether that's legitimate exploration or it's stuck somewhere.

For example, right now, it's been running 15 minutes, and I don't know why from this output i nthe console:

● Write(requirements.txt)
Wrote 2 lines to requirements.txt
telethon==1.44.0
python-dotenv==1.2.1
Interrupted · What should Claude do instead?

Change to use config.json same as c:\GitHub\DomainManagementPython\Agents\WGTaskGetNext.py instead of environment variables. Write a program like this so I can get the chat id of the "Seminar Group":

from telethon.sync import TelegramClient
client = TelegramClient('session_name', api_id, api_hash)
client.start()
for dialog in client.get_dialogs():
print(dialog.name, dialog.id)
Searched for 1 pattern, read 2 files, listed 1 directory, ran 1 shell command

MTProto Servers

Test: 149.154.167.40:443
Prod: 149.154.167.50:443
● Running 1 shell command…
⎿ $ cd "C:/GitHub/DomainManagementPython" && git check-ignore -v Agents/config.json 2>&1; echo "exit:$?"; echo "---gitignore---"; cat .gitignore 2>&1 | grep -i -E "config|env"
✻ Working… (15m 56s · ↓ 1.9k tokens)
Tip: Run claude --continue or claude --resume to resume a conversation

Diagnosed potential interactive prompt hang and prescribed debugging strategies
Diagnosed potential interactive prompt hang and prescribed debugging strategies
That "Working… (15m 56s)" timer is cumulative for the whole turn, not for the single command it's showing you — so it's not that git check-ignore is slow, it's that you can't see everything that happened in between. A few things going on:

Right now, in this session:

Press Ctrl+O — that opens the transcript viewer with everything expanded (all tool calls, all output, no collapsing). This is the fastest way to see what's actually eaten the 15 minutes without restarting anything.
If a specific bash/tool result is collapsed with (ctrl+o to expand), that same key expands it inline too.
One real risk with what it's doing: the code you asked for calls client.start() from Telethon. That method is interactive by design — on first run (no saved session file) it prompts in the terminal for your phone number, then a login code. If Claude Code actually ran that script (rather than just writing it), that prompt would be sent to a subprocess with no human on the other end, and it would just hang indefinitely waiting for input that never comes. That's a very plausible reason a "should be quick" step turns into 15+ minutes with no error. If you see git check-ignore as the last visible action but nothing since, it may actually still be sitting on that — or on a similarly blocking call earlier that got summarized away.

Going forward:

Start the session with claude --verbose so tool calls and results stream in full rather than one-line-then-collapse.
If a run passes the time you expected, don't just wait — hit Escape to interrupt and check in, the way you did here. That's the right instinct.
Worth telling it explicitly in your prompt: "don't run the script yourself, just write it — I'll run it myself since it needs an interactive phone/code login." That avoids the hang entirely for anything using Telethon's interactive auth.

Eliminated local network options and charted troubleshooting path forward
Eliminated local network options and charted troubleshooting path forward
That rules out Tailscale too. At this point you've eliminated Windows Firewall, antivirus VPN inspection (assuming you tested that), and Tailscale — the local-network suspects are pretty much exhausted. Time to shift focus to the other side.

Do these three things now, in order:

Check for a live incident: go to status.claude.com in a browser. If there's an active issue with the API or streaming, that explains everything you've been seeing and no local change will fix it — you'd just wait it out.
Check your Claude Code version:
claude --version
then

claude update
There have been recent fixes specifically targeting stream-handling/timeout bugs. If you're even a few versions behind, this alone might resolve it.

Start a completely fresh session rather than retrying in the current one:
claude --continue
won't help here — instead just start a brand new session (claude, no flags) for this Telegram task, so you're not dragging along everything read/searched in the failed attempts. Give it the same /plan request fresh.

If it still fails after all three: this is worth reporting directly rather than continuing to troubleshoot solo. File it at:

github.com/anthropics/claude-code/issues
Include: your Claude Code version, that it fails even on plan-mode/read-only tasks, and that you've ruled out firewall, AV, and Tailscale — that's genuinely useful diagnostic detail that separates your report from the vaguer ones already open, and increases the odds someone with server-side visibility can actually track down the cause.

One more small thing worth trying while you wait to hear back on any of the above — since it failed again on a retry in the same session: try switching models with /model (e.g. Sonnet if you were on Opus, or vice versa) before retrying. A few of the open reports tie this more to one specific model under load, and it's a 10-second thing to test.

claude --version
2.1.215 (Claude Code)
claude update
Current version: 2.1.215
Checking for updates to latest version...
Claude Code is up to date (2.1.215)

Orchestrated troubleshooting guidance for technical issues
Orchestrated troubleshooting guidance for technical issues
Good, that's confirmed — you're on the current version, so it's not a fixed-and-shipped bug you're missing.

That leaves two things left to check before filing a report:

status.claude.com — open it in a browser and see if there's an active incident. This takes 10 seconds and would explain everything at once if there's a live problem.

Try a genuinely fresh session (not --continue, not --resume — just claude from a new prompt) and give it a small, simple first request — something like a one-line file read, not the full Telegram task. If even that times out on a brand-new session with zero accumulated context, that's strong evidence it's not context size or your specific task — it's something wrong with the connection/route itself right now.

Try /model to switch (Sonnet ↔ Opus) and retry the same small test — a quick way to see if it's tied to one model being under heavy load.

If the fresh-session, minimal-request test still times out, you've now got a clean, reproducible case: current version, no VPN/Tailscale/firewall/AV interference, fails even on trivial requests in a brand-new session. That's exactly the kind of report worth filing at github.com/anthropics/claude-code/issues — include the version (2.1.215), your OS (Windows), and that minimal-repro detail. At that point it's genuinely out of your hands to fix locally, and the useful thing to do is get it in front of Anthropic with good diagnostic detail rather than keep guessing at causes.

Claude is AI and can make mistakes. Please double-check responses.

Claude finished the response

Verifying Tailscale's plausible connection mechanisms
Verifying Tailscale's plausible connection mechanisms
Yes, it can — and it's actually a good suspect. Tailscale runs a WireGuard-based virtual network adapter, and there are a few well-documented ways it can interfere with exactly the kind of long-lived HTTPS streaming connection Claude Code uses:

MTU mismatches

Tailscale's virtual interface typically uses an MTU around 1280–1360 bytes, smaller than your normal Ethernet/Wi-Fi MTU of 1500. If something along the path doesn't handle that cleanly, large packets can get silently dropped instead of properly fragmented — connections look "alive" (low latency, pings work) but bulk data transfer stalls or crawls. That's a very close match to a stream that opens fine but then goes idle.

Exit nodes or subnet routes

If you have an exit node enabled (routing all your internet traffic through another device on your tailnet) or subnet routes configured, every request to api.anthropic.com is taking an extra hop through that path. Any instability there — the exit node's own connection, its resource limits, etc. — becomes your bottleneck.

DNS via Tailscale (MagicDNS)

If MagicDNS is on, it can occasionally cause slow or inconsistent DNS resolution for external domains, adding delay before a connection even starts.

How to test it (fastest way — just toggle it off):

Right-click the Tailscale icon in your Windows system tray.
Click "Disconnect" (this fully stops routing traffic through Tailscale, without uninstalling anything).
Retry the same Claude Code task.
If it works cleanly, Tailscale (or something downstream of it) was the cause — reconnect after the test.
If you use Tailscale for something you need active (e.g., reaching another machine) and can't just disconnect it:

Check if you have an exit node set: tray icon → look for a checkmark next to "Exit node" — if one's selected, try unchecking it and testing again. That's the single most likely setting to cause this.
If no exit node is set and it's just providing access to specific tailnet devices, it's less likely to be routing your Anthropic traffic at all — in which case it's probably not the cause, and disconnecting won't change anything.
Given you're not using a VPN otherwise, and you do have Tailscale, checking that exit-node setting first is the highest-value 30-second check before digging into antivirus settings.

Do I type /plan only, or /plan followed by what I want to plan?

/plan followed by what you want — same message, all together. For example:

/plan Rework the Telegram chat-id script to read config.json like WGTaskGetNext.py does, and add error handling for AuthRestartError
You type it as one line and hit enter. /plan on its own with nothing after it just switches you into plan mode without giving Claude a task yet — it'll likely just ask you what you want it to plan. Putting the request right after it in the same message is the normal way to use it, and saves a round-trip.

If you're already in plan mode (from pressing Shift+Tab twice) and want to stay in it, you don't need /plan at all — just type your next request normally and it'll plan rather than execute, since the mode is already active.

I cannot tell if Claude Code is doing anything:
● API Error: Stream idle timeout - no chunks received
✻ Crunched for 4m 15s

/plan I copied GetChatId.py to MonitorTelegramGroups.py, and I added this to the config.json: "TELEGRAM_GROUPS_TO_MONITOR": "Seminar Group,-1003297250000" That parm will be a comma separate list of groups and chatids, example "Group1, Chatid1, Group2, Chatid2". I want you to save in a little text file that date/time this program last ran, and then get all the new posts to that telegram group since that date/time, write to console, and then udpate the date/time file.

⎿ Already in plan mode. No plan written yet.
38507 tokens
───────────────────────────────────────────────────────────────────────────────────────────────────────────────

Diagnosed processing status by analyzing spinner indicators and transcript states
Diagnosed processing status by analyzing spinner indicators and transcript states
Right now, from what's shown, it looks idle — not working. Here's how to tell the difference reliably:

Active/thinking: you'll see a spinner glyph with a present-tense verb and a live-incrementing timer, like ✻ Crunching… (0m 42s). That line updates continuously while a request is in flight.

Finished/idle: the verb switches to past tense with a final time, like ✻ Crunched for 4m 15s — that's a summary of a turn that already ended, not something happening now. In your log, that's exactly what you have, and it's tied to the error above it (the timeout killed that turn at 4m15s).

After that, the ⎿ Already in plan mode. No plan written yet. line is just an informational note Claude Code prints instantly when it sees /plan while you're already in plan mode — it's not a sign of processing, it's immediate local feedback.

So the empty > prompt with no spinner beneath it means nothing is currently running — it's sitting there waiting for you to send the message.

What to do:

If you already pressed Enter and it just sits like this with no spinner appearing at all, the message likely didn't submit — press Enter again.
If you're not sure whether it submitted, type /status — if a request is genuinely in flight, /status will still respond immediately (it's a local command, not an API call), which itself confirms Claude Code isn't hung.
Once it is actually working, watch for the spinner line to appear under your message with a live timer — that's your "yes, it's doing something" signal going forward.
Given the timeout you just hit, it's worth resending this one plan request fresh (maybe even in a new session, since context is at 38.5k tokens already) rather than assuming it's silently working in the background.

I have turned off all Windows firewalls, now this is what I see in Claude Code:

/plan I copied GetChatId.py to MonitorTelegramGroups.py, and I added this to the config.json: "TELEGRAM_GROUPS_TO_MONITOR": "Seminar Group,-1003297250000" That parm will be a comma separate list of groups and chatids, example "Group1, Chatid1, Group2, Chatid2". I want you to save in a little text file that date/time this program last ran, and then get all the new posts to that telegram group since that date/time, write to console, and then udpate the date/time file.
⎿ Enabled plan mode
● Read(C:\GitHub\DomainManagementPython\ClaudeConnectors\Telegram\GetChatId.py)
Read 79 lines
● Read(C:\GitHub\DomainManagementPython\ClaudeConnectors\Telegram\MonitorTelegramGroups.py)
Read 79 lines
● Read(C:\GitHub\DomainManagementPython\config.json)
Read 108 lines
● Search(pattern: "last_run|lastrun|LAST_RUN|last_checked|since_date", path: "C:\GitHub\DomainManagementPython")
⎿ Found 3 files
C:\GitHub\DomainManagementPython\CheckStatsScripts.py
C:\GitHub\DomainManagementPython\.claude\worktrees\epic-lalande\CheckStatsScripts.py
C:\GitHub\DomainManagementPython\.claude\worktrees\laughing-nightingale\CheckStatsScripts.py
● Read(C:\GitHub\DomainManagementPython\ClaudeConnectors\Telegram\requirements.txt)
Read 3 lines
● Search(pattern: "last_run|lastrun|LAST_RUN|last_checked|since_date", path: "C:\GitHub\DomainManagementPython\CheckStatsScripts.py")
⎿ Found 1 file
C:\GitHub\DomainManagementPython\CheckStatsScripts.py
● Search(pattern: "last_run|lastrun|LAST_RUN|last_checked|since_date", path: "C:\GitHub\DomainManagementPython\CheckStatsScripts.py")
⎿ Found 20 lines
67- f"WHERE seotrc_program = '{name}'")
68- logger.info("Query: " + query)
69-
70- cursor.execute(query)
71- max_rows = cursor.fetchall()
72-
73: last_runtime = "N/A"
74- if len(max_rows) > 0 and max_rows[0] and hasattr(max_rows[0], 'seotrc_datetime'):
75: last_runtime = max_rows[0].seotrc_datetime
76-
77- email_subject = f"Website-Garden.com - {name} stopped working"
78- email_body = f"""
79- {name} has been stopped working for over 12 hours.<br/>
80: Last runtime: {last_runtime}
81- """
82- # result = send_email("xxxxx@gmail.com", email_subject, email_body)
83- result = send_email(email_recipient, email_subject, email_body)
84- if result:
85- logger.info(f"Email sent to {email_recipient}")
86- else:
● API Error: Stream idle timeout - no chunks received
✻ Cogitated for 4m 58s
Try again
✻ Waiting for API response · will retry in 2m 34s · check your network

Diagnosed persistent timeout issues beyond firewall, recommended verification steps
Diagnosed persistent timeout issues beyond firewall, recommended verification steps
The firewall being disabled didn't resolve the issue, which rules out OS-level blocking since some tool calls did succeed. The timeouts are happening after multiple rapid tool calls during read-only operations, suggesting either context accumulation, a server-side problem, or Tailscale still interfering despite the firewall being off.

I should have them verify Tailscale is actually disconnected, check the status page at status.claude.com, confirm the timeout environment variable is set in the same command session where they're launching Claude Code, and try running with verbose logging to see where exactly it's hanging. Given that multiple standard troubleshooting steps haven't worked and there's a consistent pattern of timing out after ~5 minutes then recovering after ~2-3 minutes, this might warrant checking the GitHub issues or filing a bug report since it could be a systemic issue rather than a local configuration problem.

Show more
Done
Turning off the Windows Firewall didn't help — and that's actually useful information, because it rules out. It also means we've now ruled out most of the "usual suspects":

✅ Windows Firewall — off, still fails
❓ Tailscale — did you test disconnecting it? Given everything else has failed, this is now the strongest remaining candidate we haven't confirmed either way.
❓ Antivirus SSL inspection — did you test disabling that too?
If you haven't tried disconnecting Tailscale yet, that's the next thing to isolate before going further — right-click the tray icon → Disconnect → retry.

But here's what's more telling from this latest log: the failures are happening after a burst of successful tool calls (5 reads/searches completing fine), right when Claude goes to generate its actual response. That consistent "several tool calls succeed, then the API call that follows them times out" pattern — even in plan mode, which does no heavy work — is starting to look less like a local network/firewall issue and more like either:

A server-side/routing issue specific to your account or region right now, or
Context size — even in plan mode, everything read (79+79+108+3 lines, plus repeated search results) gets bundled into the next request. Two duplicate searches for the same pattern back-to-back is also a small sign something's off in how the turn is being assembled.
Given you've now ruled out firewall (and are testing Tailscale/AV), I'd do these in order:

Check status.claude.com — if there's a live incident, this explains everything and no local fix will help.
Confirm your Claude Code version: run claude --version then claude update if it's not current. Recent releases have shipped specific fixes for this exact error.
Try /clear or start a completely fresh session for this task — you're rebuilding context from scratch each retry right now, which compounds the problem every time it fails and you retry.
If it's still happening after status/version/fresh-session checks and Tailscale is ruled out, this is worth filing directly on github.com/anthropics/claude-code/issues — there are multiple open reports of this exact message, and yours (failing even on small plan-mode reads) is useful data for them, not something you're likely to resolve entirely from your end.
Given how much you've already correctly eliminated, I'd lean toward this being either a live server-side issue or a Claude Code version/context issue at this point, rather than something further to chase on your network.

I turned off Tailscale.

Do these three things now, in order:

claude update
There have been recent fixes specifically targeting stream-handling/timeout bugs. If you're even a few versions behind, this alone might resolve it.

If it still fails after all three: this is worth reporting directly rather than continuing to troubleshoot solo. File it at:

claude --version
2.1.215 (Claude Code)
claude update
Current version: 2.1.215
Checking for updates to latest version...
Claude Code is up to date (2.1.215)

That leaves two things left to check before filing a report:

status.claude.com — open it in a browser and see if there's an active incident. This takes 10 seconds and would explain everything at once if there's a live problem.

Try a genuinely fresh session (not --continue, not --resume — just claude from a new prompt) and give it a small, simple first request — something like a one-line file read, not the full Telegram task. If even that times out on a brand-new session with zero accumulated context, that's strong evidence it's not context size or your specific task — it's something wrong with the connection/route itself right now.

Try /model to switch (Sonnet ↔ Opus) and retry the same small test — a quick way to see if it's tied to one model being under heavy load.

/model

⎿ Set model to Opus 4.8 (1M context) and saved as your default for new sessions

/plan I copied GetChatId.py to MonitorTelegramGroups.py, and I added this to the config.json: "TELEGRAM_GROUPS_TO_MONITOR": "Seminar Group,-1003297259178" That parm will be a comma separate list of groups and chatids, example "Group1, Chatid1, Group2, Chatid2". I want you to save in a little text file that date/time this program last ran, and then get all the new posts to that telegram group since that date/time, write to console, and then udpate the date/time file.

⎿ Enabled plan mode

✻ Waiting for API response · will retry in 2m 32s · check your network

What Should Happen?

I should not get any timeouts or API errors.

Error Messages/Logs

> /plan I copied GetChatId.py to MonitorTelegramGroups.py, and I added this to the config.json: "TELEGRAM_GROUPS_TO_MONITOR": "Seminar Group,-1003297259178"  That parm will be a comma separate list of groups and chatids, example "Group1, Chatid1, Group2, Chatid2".  I want you to save in a little text file that date/time this program last ran, and then get all the new posts to that telegram group since that date/time, write to console, and then udpate the date/time file.
  ⎿  Enabled plan mode

I'll research the existing code before planning. Let me look at the relevant files.

● Read(C:\GitHub\DomainManagementPython\ClaudeConnectors\Telegram\MonitorTelegramGroups.py)
Read 79 lines

● Read(C:\GitHub\DomainManagementPython\ClaudeConnectors\Telegram\GetChatId.py)
Read 79 lines

● Read(C:\GitHub\DomainManagementPython\ClaudeConnectors\Telegram\requirements.txt)
Read 3 lines

Let me look at the config and check for existing patterns for state/timestamp files.

● Bash(grep -n "TELEGRAM" config.json)
100:,   "TELEGRAM_API_ID": "xxxxx",
101:   "TELEGRAM_API_HASH":  "xxxx",
102:   "TELEGRAM_PHONE": "xxxx",
103:   "TELEGRAM_TEST_SERVER": "149.154.167.40:443",
104:   "TELEGRAM_PROD_SERVER": "149.154.167.50:443",
105:   "TELEGRAM_GROUPS_TO_MONITOR": "Seminar Group,-1003297259178"

● Bash(cd /c/GitHub/DomainManagementPython/ClaudeConnectors/Telegram && ls -la)
total 77
drwxr-xr-x 1 nwalt 197610     0 Jul 19 22:07 ./
drwxr-xr-x 1 nwalt 197610     0 Jul 19 19:04 ../
-rw-r--r-- 1 nwalt 197610  2630 Jul 19 22:03 GetChatId.py
-rw-r--r-- 1 nwalt 197610  2630 Jul 19 22:03 MonitorTelegramGroups.py
drwxr-xr-x 1 nwalt 197610     0 Jul 19 20:02 __pycache__/
-rw-r--r-- 1 nwalt 197610    38 Jul 19 19:30 requirements.txt
-rw-r--r-- 1 nwalt 197610 57344 Jul 19 22:04 telegram_session.session

✻ Waiting for API response · will retry in 1m 59s · check your network

Then last line changes to this: 

API Error: Stream idle timeout - no chunks received

Steps to Reproduce

For me it is happening every time, doing almost anything.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.215

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

then it changes to this:

So now I just tried in Claude Desktop, on the Code tab, same issue:

But I haven't had any issues in the desktop in chat mode.

I finally just used the Home/Chat part of Claude Desktop, pasted my code there, same prompt, and copied the code back out So it's not a lot of time or tokens to do the what I requested.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗