cmux can freeze for 5-10 seconds after switching back from another app

[miiiinju1]

cmux version

0.63.2

macOS version

macOS 14.6

Mac chip

Apple Silicon (M1/M2/M3/M4)

Installation method

Direct download (DMG)

Can you reproduce this on cmux NIGHTLY?

I could not test NIGHTLY

Bug description

I can reliably trigger long UI stalls when returning to cmux after using another app for a while.

The most consistent repro is:

1. Open cmux and use it normally with a few tabs or splits.
2. Switch to Slack or another app for somewhere between 30 seconds
   and a few minutes.
3. Return to cmux.
4. As soon as cmux becomes active again, immediately scroll, click a
   tab, click inside the terminal, or press Cmd+B.

At that point, cmux often becomes mostly unresponsive for around 5 to 10 seconds. The window is still visible, but clicks, scrolling, and keyboard input mostly do nothing until it catches up.

What makes me think this is app/UI-side rather than shell-side is that I can also trigger a very similar stall by toggling the sidebar with Cmd+B, and sometimes by heavy scrolling alone. Because of that, it seems more likely that cmux is getting stuck in some main-thread UI/layout/reconciliation path when it becomes active again, especially around the tab bar, sidebar, and scrolling-related paths.

I am seeing this on stable 0.63.2 even though the changelog mentions fixes around sidebar layout loops, so this may be a remaining variant or a regression in the same general area.

Expected behavior

Returning to cmux should be immediate and responsive.

Switching back to the app after it has been in the background, toggling the sidebar, or scrolling around the UI should not block the window for multiple seconds.

Steps to reproduce

1. Open cmux.
2. Create a few tabs or splits so the UI has some normal state to manage.
3. Use cmux normally for a minute or two.
4. Switch to Slack or another app and leave cmux in the background
   for 30 seconds to a few minutes.
5. Click back into cmux.
6. Immediately do one of the following:
   • scroll
   • click a tab
   • click inside the terminal
   • press Cmd+B
7. Observe that cmux can freeze for around 5 to 10 seconds while the window remains visible.

Other paths that seem to trigger the same issue for me:

1. Toggle the sidebar with Cmd+B.
2. Scroll aggressively in the terminal or around the tab/sidebar area.
3. In general, the issue is easier to hit when cmux has been inactive in the background for a while and I interact with it right after coming back.

Shell and environment

zsh.

I do not think the shell itself is the main bottleneck here. The reason is that the same stall can be triggered by UI actions like sidebar toggle and heavy scrolling, not just by returning focus to a terminal prompt.

Relevant logs or crash reports

I am not attaching the raw files yet, but I did check local diagnostics while reproducing this.

From a macOS hang report:

-[NSWindow(NSConstraintBasedLayoutInternal) layoutIfNeeded]
-[NSView _layoutSubtreeWithOldSize:]
ObservationTracking.cancel()

From manual sample traces taken during the freeze:

TabItemView.body.getter
TabItemView.shortcutHintWidth(for:)
-[NSScrollView tile]

So from local diagnostics, this still looks more like a main-thread UI/layout stall than shell-side latency.

Screenshots or screen recordings

No recording attached yet.

If needed, I can try to capture one, but the issue is straightforward to notice in person because the app stays visible and then becomes mostly unresponsive for several seconds right after returning to it.

Additional context

A few things I already tried:

• reducing sidebar detail
• enabling minimal mode
• starting with the sidebar hidden

Those reduced one trigger a little, but they did not eliminate the issue.

From outside observation, the issue feels tied to app re-activation after cmux has been in the background for a while. It also seems related to the tab bar, sidebar, and scroll/layout paths, because those are the easiest places where I can trigger the same kind of stall even without doing anything unusual inside the shell itself.