[Bug - macOS] 🐛 "Open folder" dialog freezes the whole app for ~50–60 seconds (UI thread blocked in NSOpenPanel)

[jjloneman-jetblue]

🐛 Summary

• In the desktop app, Projects → + → Open folder hangs the entire app:

  
  • Spinning cursor and "Not Responding" for 50–60 seconds
  • The macOS folder picker then appears and works normally

• It happens on every subsequent Open folder action as well

💻 Environment

• GitHub Copilot desktop app 1.1.29
  • Installed with brew install --cask github-copilot-app
• macOS Tahoe 26.7.1
• MacBook Pro M3, 16-inch, Nov 2023, 18 GB memory
  • 240 GB available of 495 GB

🔁 Steps to reproduce

1. Open the app.
2. Go to the Projects tab and click the + button.
3. Click Open folder.
4. The app freezes for ~50–60s, then the picker appears.

GitHub.Copilot.Desktop.App.Bug.Reproduction.mp4

🔎 What I found

• Other pickers on the same machine are instant
  • VS Code, TextEdit, and File > Open
• The app's own log records every freeze (details under Logs below)
  • 7 renderer_freeze warnings in about 20 minutes
  • 5 lasted 51–59s, and 2 were shorter (9.5s and 12.6s)
• A sample of the frozen app shows the main thread blocked while creating the picker
  • NSOpenPanel openPanel → _initBridgeAndStuff → HIRunLoopSemaphore wait
  • It is waiting on the macOS Open and Save Panel service
  • A tokio worker is blocked in tauri_plugin_dialog::blocking_pick_folder
• A sample of the Open and Save Panel service at the same moment shows it idle
  • So the delay isn't the panel doing work

✅ Expected behavior

• The picker opens immediately
• The UI stays responsive

💡 Suggestion

• Open the folder picker without blocking the main/UI thread
• Ideally add a timeout, so a slow panel service can't freeze the whole app

📝 Logs

📜 App log: freeze monitor warnings

What this is

• Lines from the app's own log, ~/.copilot/logs/github-app.<pid>.log
  • Only the renderer_freeze warnings are included
• The app runs a watchdog that logs two lines per freeze
  • main renderer unresponsive: the UI missed heartbeats for 3,000 ms
  • main renderer heartbeat restored: heartbeat_gap_ms is the total time the UI was stuck
• Timestamps are UTC (17:01Z is 13:01 EDT)

Analysis

• 7 freezes in about 20 minutes, each right after clicking Open folder
  • 5 lasted 51–59s (51050, 52045, 53871, 54075, 59235 ms)
  • 2 were shorter: 9.5s and 12.6s
• The consistent 50–60s looks like a fixed timeout or a blocked call, not random slowness
• main_thread_gap_ms is about 1,005 in every case and confirmed=false
  • The log alone doesn't show which thread is stuck, hence the stack samples below
• The last line has no matching "restored" line because the file was captured during a freeze

Log

2026-10-13T17:01:05.209791Z  WARN task_spawn{task="renderer_freeze_monitor"}: github_app_desktop_services::renderer_freeze: main renderer unresponsive route="other" interaction="pointer" threshold_ms=3000
2026-10-13T17:01:14.233658Z  WARN github_app_desktop_services::renderer_freeze: main renderer heartbeat restored route="other" interaction="pointer" heartbeat_gap_ms=12613 main_thread_gap_ms=1005 confirmed=false
2026-10-13T17:01:44.209703Z  WARN task_spawn{task="renderer_freeze_monitor"}: github_app_desktop_services::renderer_freeze: main renderer unresponsive route="other" interaction="pointer" threshold_ms=3000
2026-10-13T17:02:40.025086Z  WARN github_app_desktop_services::renderer_freeze: main renderer heartbeat restored route="other" interaction="pointer" heartbeat_gap_ms=59235 main_thread_gap_ms=1005 confirmed=false
2026-10-13T17:02:57.211298Z  WARN task_spawn{task="renderer_freeze_monitor"}: github_app_desktop_services::renderer_freeze: main renderer unresponsive route="session" interaction="pointer" threshold_ms=3000
2026-10-13T17:03:48.157014Z  WARN github_app_desktop_services::renderer_freeze: main renderer heartbeat restored route="session" interaction="pointer" heartbeat_gap_ms=54075 main_thread_gap_ms=1006 confirmed=false
2026-10-13T17:04:41.211284Z  WARN task_spawn{task="renderer_freeze_monitor"}: github_app_desktop_services::renderer_freeze: main renderer unresponsive route="session" interaction="pointer" threshold_ms=3000
2026-10-13T17:05:28.293007Z  WARN github_app_desktop_services::renderer_freeze: main renderer heartbeat restored route="session" interaction="pointer" heartbeat_gap_ms=51050 main_thread_gap_ms=1005 confirmed=false
2026-10-13T17:06:43.212990Z  WARN task_spawn{task="renderer_freeze_monitor"}: github_app_desktop_services::renderer_freeze: main renderer unresponsive route="session" interaction="pointer" threshold_ms=3000
2026-10-13T17:07:33.154086Z  WARN github_app_desktop_services::renderer_freeze: main renderer heartbeat restored route="session" interaction="pointer" heartbeat_gap_ms=53871 main_thread_gap_ms=1005 confirmed=false
2026-10-13T17:11:35.211719Z  WARN task_spawn{task="renderer_freeze_monitor"}: github_app_desktop_services::renderer_freeze: main renderer unresponsive route="session" interaction="pointer" threshold_ms=3000
2026-10-13T17:11:40.772906Z  WARN github_app_desktop_services::renderer_freeze: main renderer heartbeat restored route="session" interaction="pointer" heartbeat_gap_ms=9457 main_thread_gap_ms=1005 confirmed=false
2026-10-13T17:13:15.211799Z  WARN task_spawn{task="renderer_freeze_monitor"}: github_app_desktop_services::renderer_freeze: main renderer unresponsive route="session" interaction="pointer" threshold_ms=3000
2026-10-13T17:14:03.392819Z  WARN github_app_desktop_services::renderer_freeze: main renderer heartbeat restored route="session" interaction="pointer" heartbeat_gap_ms=52045 main_thread_gap_ms=1005 confirmed=false
2026-10-13T17:20:49.215570Z  WARN task_spawn{task="renderer_freeze_monitor"}: github_app_desktop_services::renderer_freeze: main renderer unresponsive route="session" interaction="pointer" threshold_ms=3000

🧵 App stack sample: sample-app-main-thread.txt (frozen app)

What this is

• Output of macOS /usr/bin/sample on the github process (pid 4421): 12 seconds at 1 ms intervals
  • Captured right when the freeze monitor logged "unresponsive", so it shows what the app was doing during the freeze
• A call graph: which functions each thread was in, and how many samples landed there

Analysis

• The main (UI) thread spent all 9,021 of its samples in one stack
  • rfd … pick_folder_async → Panel::build_pick_folder → NSOpenPanel openPanel
  • → NSSavePanel _initBridgeAndStuff → HIRunLoopSemaphore wait:
• The UI thread is blocked while creating the NSOpenPanel, waiting for a reply from the system Open and Save Panel service
  • The dialog hasn't appeared yet, so the delay is before the picker is shown
• A tokio worker thread is blocked in tauri_plugin_dialog::blocking_pick_folder
• Since the picker is created on the main thread, a slow reply freezes the whole window
• The sample doesn't show why the service takes ~50s to reply, only that the app waits with no timeout

Attachment

sample-app-main-thread.txt

🗂️ Panel service sample: sample-panel-service.txt (macOS Open and Save Panel service)

What this is

• Output of /usr/bin/sample on com.apple.appkit.xpc.openAndSavePanelService (pid 11146): 12 seconds at 1 ms intervals, captured at the same moment as the app sample
• This is the macOS system process that draws open and save dialogs on behalf of apps

Analysis

• In this sample the service is idle, waiting in mach_msg
  • It wasn't busy and wasn't stuck in a file-system call
• At the same moment the app was still waiting on it, so the delay may be in the connection or hand-off between the app and the service
• An earlier capture (not attached) caught the service in FinderKit, enumerating ~/Desktop (DesktopFolderNode → FetchISIcon → getattrlist)
  • So where the time goes may vary between attempts
• VS Code and TextEdit open the same picker instantly on this machine, so the slowdown is specific to how this app requests it

Attachment

sample-panel-service.txt