claude-code - 💡(How to fix) Fix Desktop app (Windows): background sessions pause and timer resets when switching to another session [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#48045Fetched 2026-04-15 06:34:52
View on GitHub
Comments
2
Participants
2
Timeline
5
Reactions
0
Timeline (top)
labeled ×3commented ×2

When a session is running work in the background (agent call, long bash command, web research, etc.), switching to another session via the sidebar appears to suspend the first session's execution. On return, the elapsed-time timer resets to zero and little to no progress has been made, sometimes none at all.

Root Cause

Architectural note

The desktop app does not support multiple visible session windows; sessions are switched one-at-a-time via the sidebar. This means users cannot work around the bug by keeping a session in focus while doing other work, because the workflow requires switching away.

RAW_BUFFERClick to expand / collapse

Environment

  • Platform: Windows 11 Pro (10.0.26200)
  • App: Claude Code Desktop app
  • Version: 1.2278.0 (e5213f)
  • First observed: ~April 13-14, 2026

Summary

When a session is running work in the background (agent call, long bash command, web research, etc.), switching to another session via the sidebar appears to suspend the first session's execution. On return, the elapsed-time timer resets to zero and little to no progress has been made, sometimes none at all.

Steps to reproduce

  1. In Session A, kick off a long-running task (e.g., an Agent call that will take 30-60 seconds, or a long Bash command)
  2. While Session A is processing, switch to Session B via the sidebar
  3. Wait 60-120 seconds
  4. Switch back to Session A
  5. Observe: elapsed-time counter has reset, and the in-progress tool call has not advanced (or has advanced only slightly)

Expected behavior

Sessions run independently of which one is currently visible. Per the docs, background work should continue regardless of focus. Related issue #36418 describes the same class of bug for the CLI variant.

Actual behavior

The background session is effectively paused while not visible. The timer reset on return is the strongest signal: if work were continuing and only the display were stale, the timer would show real elapsed time.

Architectural note

The desktop app does not support multiple visible session windows; sessions are switched one-at-a-time via the sidebar. This means users cannot work around the bug by keeping a session in focus while doing other work, because the workflow requires switching away.

Hypothesis

Likely Chromium/Electron background-window throttling suspending the render process or JS event loop. Flags like `--disable-background-timer-throttling`, `--disable-backgrounding-occluded-windows`, and `--disable-renderer-backgrounding` would address this class of issue but do not appear to be set (or exposed in settings).

Impact

Fundamentally breaks the multi-session workflow. Users cannot run any long-running task in one session and use another in the meantime.

extent analysis

TL;DR

The issue can be potentially resolved by setting flags to disable background-window throttling, such as --disable-background-timer-throttling, --disable-backgrounding-occluded-windows, and --disable-renderer-backgrounding, to prevent the suspension of the render process or JS event loop when a session is not visible.

Guidance

  • Investigate the possibility of setting the aforementioned flags as command-line arguments when launching the Claude Code Desktop app to see if it mitigates the issue.
  • Verify that the flags are not already set or exposed in the app's settings, as this could be a straightforward solution.
  • Consider testing the app with a different Electron or Chromium version to determine if the issue is specific to the current version being used.
  • Look into the documentation for the --disable-background-timer-throttling flag and others to understand their implications on performance and security.

Example

No code snippet is provided as the issue seems to be related to command-line flags rather than code changes.

Notes

The effectiveness of the suggested flags in resolving the issue is uncertain without further testing. Additionally, the potential performance and security implications of disabling background-window throttling should be carefully considered.

Recommendation

Apply the workaround by setting the flags --disable-background-timer-throttling, --disable-backgrounding-occluded-windows, and --disable-renderer-backgrounding as command-line arguments when launching the app, as this is the most direct approach to addressing the suspected root cause of the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Sessions run independently of which one is currently visible. Per the docs, background work should continue regardless of focus. Related issue #36418 describes the same class of bug for the CLI variant.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING