Warp freezes and becomes unresponsive when opening or running agents

[Santiago0412]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

Summary
Warp frequently freezes and becomes completely unresponsive when opening or running agents, blocking normal workflow.

Problem
When interacting with agents (both opening and running), Warp intermittently enters a frozen state where the whole window stops responding and must be force-quit.

Expected behavior
Warp should remain responsive while opening/running agents, and long-running tasks should not freeze the app UI.

Actual behavior
The entire Warp window becomes unresponsive and requires force quit.

Artifacts
None attached.

Warp version
v0.2026.04.29.08.57.stable_01

To reproduce

Reproduction steps or desired workflow

1. Open Warp.
2. Open an agent or run agent tasks.
3. After repeated usage, Warp may freeze unexpectedly.
4. App becomes fully unresponsive and must be force-quit.

Expected behavior

No response

Screenshots, videos, and logs

No response

Operating system (OS)

macOS

Operating system and version

macOS 26.3.1

Shell Version

No response

Current Warp version

No response

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

No response

Additional context

No response

Does this block you from using Warp daily?

No

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None

[oz-for-oss]

@Santiago0412

Here's what I found while triaging this issue:

Thanks for the report. I could not identify a matching duplicate; because this is a full-app hang, a macOS Sample Process captured while Warp is frozen would be the most useful next artifact.

I have a few follow-up questions before I can narrow this down:

1. Can you attach a macOS Sample Process captured while Warp is frozen?
2. Which agent surface most reliably triggers the freeze: opening the Conversations/Agents panel, restoring a past conversation, starting a new Warp Agent/Oz run, or running a third-party CLI agent like Claude Code/Codex?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that intermittent macOS full-window freezes while opening or running agents look like an agent-surface responsiveness bug, but the report lacks the diagnostics needed to isolate the blocking path..

Triage summary

This looks like an agent-related responsiveness bug on macOS: the whole Warp window intermittently freezes while opening or running agents and must be force-quit. The report is actionable for routing, but not yet actionable for implementation because it lacks a deterministic trigger and hang diagnostics.

Reproducibility

repro:low. The report gives the affected platform and a plausible workflow, but the reproduction is intermittent (after repeated usage) and there are no logs, process samples, videos, or debugging IDs attached.

Likely root cause

The most likely area is a client-side stall in the agent UI/runtime path rather than an isolated backend failure, because the entire app window becomes unresponsive. Relevant code paths include:

• app/src/ai/agent_management/view.rs: opening agent sessions from the management view dispatches the selected task/conversation open action.
• app/src/ai/agent_conversations_model.rs and app/src/ai/agent_conversations_model/entry.rs: the agent/conversation list combines local conversations, historical metadata, cloud conversation metadata, and ambient-agent tasks, then sorts/filters them for the UI.
• app/src/terminal/view/ambient_agent/model.rs and app/src/ai/ambient_agents/spawn.rs: cloud/Oz agent startup, progress updates, and task polling.
• app/src/ai/blocklist/action_model.rs: local agent action execution and UI updates for agent output.
• app/src/ai/active_agent_views_model.rs: tracking active agent conversations and ambient sessions across panes/tabs.

Without a macOS hang sample or logs from the frozen state, I cannot tell whether the UI thread is blocked by rendering/layout, a large conversation/history/task load, repeated polling/updates, or a local CLI-agent output path.

Duplicate check

I enumerated the repository's open issues and recent closed issues. I found related but not matching reports, such as #8409 (Claude Code sessions causing high CPU hangs) and #9899 (Windows process kill when a TUI agent streams large output), but not two existing issues with the same macOS full-window freeze while opening/running Warp agents. No duplicate is being proposed.

Suggested routing

Start with the Agent surface owners because the trigger is opening/running agents. If the reporter provides a macOS Sample Process showing the main thread blocked in rendering/windowing, also involve the UI framework owners.

Question reasoning

1. Can you attach a macOS Sample Process captured while Warp is frozen? — A hang sample is the highest-value artifact for a full-window freeze because it can show what the main thread and agent-related worker tasks are blocked on.
2. Which agent surface most reliably triggers the freeze: opening the Conversations/Agents panel, restoring a past conversation, starting a new Warp Agent/Oz run, or running a third-party CLI agent like Claude Code/Codex? — The current report says both opening and running agents; narrowing the exact surface changes owner routing and the most relevant code path.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[Santiago0412]

1.32 s 100.0% 0 s Warp (17539)
869.00 ms 65.7% 0 s Main Thread (0x113038e)
869.00 ms 65.7% 0 s start
869.00 ms 65.7% 0 s main
869.00 ms 65.7% 0 s std::rt::lang_start_internal::h1e9a2dfabf97dcbe
869.00 ms 65.7% 0 s _RNCINvNtCsiThrkg7suPy_3std2rt10lang_startINtNtCskzPJi2J8k3N_4core6result6ResultuNtCslwskEwbRmsD_6anyhow5ErrorEE0Csd2TWkaO3QFk_6stable
869.00 ms 65.7% 0 s _RINvNtNtCsiThrkg7suPy_3std3sys9backtrace28___rust_begin_short_backtraceFEINtNtCskzPJi2J8k3N_4core6result6ResultuNtCslwskEwbRmsD_6anyhow5ErrorEB19_ECsd2TWkaO3QFk_6stable
869.00 ms 65.7% 0 s _RNvCsd2TWkaO3QFk_6stable4main
869.00 ms 65.7% 0 s _RNvCs19NY7OrRqyS_4warp3run
869.00 ms 65.7% 0 s _RNvCs19NY7OrRqyS_4warp12run_internal
869.00 ms 65.7% 0 s -[NSApplication run]
869.00 ms 65.7% 0 s -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:]
869.00 ms 65.7% 0 s -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
869.00 ms 65.7% 0 s _DPSNextEvent
869.00 ms 65.7% 0 s _DPSBlockUntilNextEventMatchingListInMode
869.00 ms 65.7% 0 s _BlockUntilNextEventMatchingListInMode
869.00 ms 65.7% 0 s ReceiveNextEventCommon
869.00 ms 65.7% 0 s RunCurrentEventLoopInMode
869.00 ms 65.7% 0 s _CFRunLoopRunSpecificWithOptions
869.00 ms 65.7% 0 s __CFRunLoopRun
867.00 ms 65.5% 0 s CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE
867.00 ms 65.5% 0 s _dispatch_main_queue_callback_4CF
867.00 ms 65.5% 0 s _dispatch_main_queue_drain
867.00 ms 65.5% 0 s _dispatch_main_queue_drain.cold.5
867.00 ms 65.5% 0 s _dispatch_client_callout
867.00 ms 65.5% 0 s RINvNvCsat2Xirftc7y_8dispatch20context_and_function20work_execute_closureNCNvXs2_NtNtNtCs9Yhts1qNoBy_6warpui8platform3mac8delegateNtB1h_16DispatchDelegateNtNtCs5S3WQRiNijr_11warpui_core8platform16DispatchDelegate18run_on_main_thread0EB1n
867.00 ms 65.5% 0 s RNvMs1_NtCscsj2eMbt2Yt_10async_task3rawINtB5_7RawTaskINtNvMs4_NtB7_8runnableINtBY_7BuilderpE11spawn_local7CheckedINtNtCskzPJi2J8k3N_4core3pin3PinINtNtCsganj50Cd8Gx_5alloc5boxed3BoxDNtNtNtB1S_6future6future6Futurep6OutputuEL_EEEuNCNvMs0_NtNtNtCs5S3WQRiNijr_11warpui_core5async6native8executorNtB3M_10Foreground11spawn_boxed0uE3runB3S
864.00 ms 65.3% 0 s RNCINvMsb_NtNtCs5S3WQRiNijr_11warpui_core4core3appNtB8_10AppContext18spawn_stream_localINtCs2XUX5FM04yg_13async_channel8ReceiverNtCs9Kta5XUAdIb_7watcher26BulkFilesystemWatcherEventEEs_0B24
864.00 ms 65.3% 0 s _RNvMsb_NtNtCs5S3WQRiNijr_11warpui_core4core3appNtB5_10AppContext17relay_task_output
864.00 ms 65.3% 0 s _RNvMsb_NtNtCs5S3WQRiNijr_11warpui_core4core3appNtB5_10AppContext13flush_effects
653.00 ms 49.4% 0 s RNCINvMNtNtNtCs5S3WQRiNijr_11warpui_core4core5model7contextINtB5_12ModelContextNtNtCsiEq1AmBZczd_13repo_metadata11local_model22LocalRepoMetadataModelE18subscribe_to_modelNtCs9Kta5XUAdIb_7watcher21BulkFilesystemWatcherNvMs0_B1h_B1f_20handle_watcher_eventE0B1j
653.00 ms 49.4% 0 s _RNvMs0_NtCsiEq1AmBZczd_13repo_metadata11local_modelNtB5_22LocalRepoMetadataModel20handle_watcher_event
650.00 ms 49.1% 0 s _RNvMs0_NtCsiEq1AmBZczd_13repo_metadata11local_modelNtB5_22LocalRepoMetadataModel24find_repository_for_path
649.00 ms 49.1% 0 s _RNvMNtCszY1PFNDAmy_9warp_util17standardized_pathNtB2_16StandardizedPath24from_local_canonicalized
1.00 ms  0.1% 0 s _RNvMs0_NtCsiEq1AmBZczd_13repo_metadata11local_modelNtB5_22LocalRepoMetadataModel31find_repository_for_path_string
2.00 ms  0.2% 0 s RNvMNtCsgwAy3Gy2nzZ_9hashbrown11rustc_entryINtNtB4_3map7HashMapNtNtCszY1PFNDAmy_9warp_util17standardized_path16StandardizedPathNtNtCsiEq1AmBZczd_13repo_metadata11local_model10RepoUpdateNtNtNtCsiThrkg7suPy_3std4hash6random11RandomStateE11rustc_entryB25
2.00 ms  0.2% 0 s _RINvYNtNtNtCsiThrkg7suPy_3std4hash6random11RandomStateNtNtCskzPJi2J8k3N_4core4hash11BuildHasher8hash_oneRNtNtCszY1PFNDAmy_9warp_util17standardized_path16StandardizedPathECsiEq1AmBZczd_13repo_metadata
1.00 ms  0.1% 0 s _RNvXs9_NtCsganj50Cd8Gx_5alloc3vecINtB5_3VecNtNtCsfsfTng187Ug_6ignore9gitignore9GitignoreENtNtCskzPJi2J8k3N_4core5clone5Clone5cloneCsiEq1AmBZczd_13repo_metadata
1.00 ms  0.1% 0 s _RNvXs9_NtCsganj50Cd8Gx_5alloc3vecINtB5_3VecNtCs3b4DxfhoNT7_7globset20GlobSetMatchStrategyENtNtCskzPJi2J8k3N_4core5clone5Clone5cloneCsiEq1AmBZczd_13repo_metadata
209.00 ms 15.8% 0 s RNCINvMNtNtNtCs5S3WQRiNijr_11warpui_core4core5model7contextINtB5_12ModelContextNtNtCsiEq1AmBZczd_13repo_metadata7watcher16DirectoryWatcherE18subscribe_to_modelNtCs9Kta5XUAdIb_7watcher21BulkFilesystemWatcherNvMB1h_B1f_20handle_watcher_eventE0B1j
209.00 ms 15.8% 0 s _RNvMNtCsiEq1AmBZczd_13repo_metadata7watcherNtB2_16DirectoryWatcher20handle_watcher_event
203.00 ms 15.3% 0 s RNCNvMNtCsiEq1AmBZczd_13repo_metadata7watcherNtB4_16DirectoryWatcher20handle_watcher_event0B6
5.00 ms  0.4% 0 s _RNvMNtCszY1PFNDAmy_9warp_util17standardized_pathNtB2_16StandardizedPath24from_local_canonicalized
1.00 ms  0.1% 0 s RINvXsc_NtNtCs5S3WQRiNijr_11warpui_core4core3appNtB6_10AppContextNtNtNtB8_5model6handle11UpdateModel12update_modelNtNtCsiEq1AmBZczd_13repo_metadata7watcher9TaskQueueNCNvMB1Q_NtB1Q_16DirectoryWatcher20handle_watcher_events5_0uEB1S
1.00 ms  0.1% 0 s _RNvMsb_NtNtCs5S3WQRiNijr_11warpui_core4core3appNtB5_10AppContext14update_windows
1.00 ms  0.1% 0 s RNCINvMsb_NtNtCs5S3WQRiNijr_11warpui_core4core3appNtB8_10AppContext22insert_window_internalNCINvB4_13insert_windowNtNtCs19NY7OrRqyS_4warp9root_view8RootViewNCNvB1Q_18open_from_restoreds1_0E0Es8_0B1S
1.00 ms  0.1% 0 s _RNvMsb_NtNtCs5S3WQRiNijr_11warpui_core4core3appNtB5_10AppContext20remove_dropped_items
1.00 ms  0.1% 1.00 ms _RNvMs5_NtCs5S3WQRiNijr_11warpui_core4coreNtB5_9RefCounts12take_dropped
3.00 ms  0.2% 0 s RNCINvMsb_NtNtCs5S3WQRiNijr_11warpui_core4core3appNtB8_10AppContext11spawn_localINtNtCsgep8vjU7LYo_15futures_channel7oneshot8ReceiverINtNtCskzPJi2J8k3N_4core6result6ResultTINtNtCsganj50Cd8Gx_5alloc3vec3VecNtNtCsiEq1AmBZczd_13repo_metadata11local_model16FileTreeMutationENtNtCszY1PFNDAmy_9warp_util17standardized_path16StandardizedPathbENtNtCs3Zr0rpycmP8_12futures_util9abortable7AbortedEEE0B3l
3.00 ms  0.2% 0 s _RNvMsb_NtNtCs5S3WQRiNijr_11warpui_core4core3appNtB5_10AppContext17relay_task_output
3.00 ms  0.2% 0 s RNSNvYNCINvMNtNtNtCs5S3WQRiNijr_11warpui_core4core5model7contextINtBa_12ModelContextNtNtCsiEq1AmBZczd_13repo_metadata11local_model22LocalRepoMetadataModelE11spawn_localINtNtCsgep8vjU7LYo_15futures_channel7oneshot8ReceiverINtNtCskzPJi2J8k3N_4core6result6ResultTINtNtCsganj50Cd8Gx_5alloc3vec3VecNtB1m_16FileTreeMutationENtNtCszY1PFNDAmy_9warp_util17standardized_path16StandardizedPathbENtNtCs3Zr0rpycmP8_12futures_util9abortable7AbortedEENCINvB9_15spawn_abortableNCNvMs0_B1m_B1k_20handle_watcher_event0NCINvB9_5spawnB7p_NCB7r_s_0uE0NCB84_s_0Es_0uE0INtNtNtB3C_3ops8function6FnOnceTQDNtNtB3C_3any3AnyEL_INtNtB4f_5boxed3BoxB9j_EQNtNtBe_3app10AppContextNtNtBe_6entity8EntityIdEE9call_once6vtableB1o
3.00 ms  0.2% 0 s _RNvMs0_NtCsiEq1AmBZczd_13repo_metadata11local_modelNtB5_22LocalRepoMetadataModel25apply_file_tree_mutations
1.00 ms  0.1% 0 s _RNvMNtCszY1PFNDAmy_9warp_util17standardized_pathNtB2_16StandardizedPath14try_from_local
1.00 ms  0.1% 0 s _RNvMs_NtNtCsiEq1AmBZczd_13repo_metadata15file_tree_store15file_tree_stateNtB4_16FileTreeMapStore20insert_entry_at_path
1.00 ms  0.1% 0 s _RNvXCsgwAy3Gy2nzZ_9hashbrownNtNtCszY1PFNDAmy_9warp_util17standardized_path16StandardizedPathINtB2_10EquivalentINtNtCsganj50Cd8Gx_5alloc4sync3ArcBq_EE10equivalentCsiEq1AmBZczd_13repo_metadata
2.00 ms  0.2% 0 s __CFRunLoopDoSources0
2.00 ms  0.2% 0 s __CFRunLoopDoSource0
2.00 ms  0.2% 0 s CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION
78.00 ms  5.9% 0 s background-executor-7 (0x11305df)
78.00 ms  5.9% 0 s thread_start
78.00 ms  5.9% 0 s _pthread_start
75.00 ms  5.7% 0 s notify-rs fsevents loop (0x113080f)
75.00 ms  5.7% 0 s thread_start
75.00 ms  5.7% 0 s _pthread_start
70.00 ms  5.3% 0 s notify-rs fsevents loop (0x11306e9)
62.00 ms  4.7% 0 s background-executor-13 (0x11305e5)
56.00 ms  4.2% 0 s background-executor-2 (0x11305da)
40.00 ms  3.0% 0 s notify-rs debouncer loop (0x1130610)
38.00 ms  2.9% 0 s notify-rs debouncer loop (0x113060b)
16.00 ms  1.2% 0 s notify-rs fsevents loop (0x113060f)
15.00 ms  1.1% 0 s PTY reader (0x11306de)
2.00 ms  0.2% 0 s Warp (0x11305e7)
1.00 ms  0.1% 0 s Warp (0x1130e7c)
1.00 ms  0.1% 0 s async-process (0x113062f)

[oz-for-oss]

@Santiago0412

Here's what I found while triaging this issue:

The Activity Monitor sample points to Warp doing filesystem/project metadata work on the main thread while processing file changes, which fits an agent workflow that creates or edits files. Because the repro is still intermittent, the exact agent workflow and a fuller hang sample would help confirm the fix path.

I have a few follow-up questions before I can narrow this down:

1. What exact agent workflow most reliably triggers the freeze (for example: opening a Warp Agent, running a local/cloud agent, using Claude/Codex CLI, editing many files, or running a build)?
2. Can you attach the full Activity Monitor sample or spindump captured while Warp is unresponsive, rather than only the excerpt pasted in the comment?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that intermittent macOS full-window freezes during agent workflows appear tied to main-thread filesystem watcher/repo metadata processing, but the exact reproducing workflow and full hang profile are still missing..

Triage summary

The report is a macOS bug where Warp intermittently becomes fully unresponsive while opening or running agents. The reporter's added Activity Monitor sample is actionable: most sampled main-thread time is under the foreground executor flushing filesystem watcher effects, especially repo metadata watcher handling and path canonicalization.

Evidence

• Version: v0.2026.04.29.08.57.stable_01 on macOS 26.3.1.
• Symptom: whole Warp window freezes and requires force quit during repeated agent usage.
• The sample shows main-thread work in AppContext::flush_effects after a BulkFilesystemWatcher event, with major time under LocalRepoMetadataModel::handle_watcher_event / find_repository_for_path / StandardizedPath::from_local_canonicalized, plus additional time in DirectoryWatcher::handle_watcher_event.

Likely code path

• crates/watcher/src/lib.rs: BulkFilesystemWatcher::new streams debounced watcher events back into the UI model system via ctx.spawn_stream_local.
• crates/repo_metadata/src/local_model.rs: LocalRepoMetadataModel::handle_watcher_event iterates added/modified/deleted/moved paths and calls find_repository_for_path; for existing paths that calls StandardizedPath::from_local_canonicalized synchronously before prefix matching tracked repos.
• crates/repo_metadata/src/watcher.rs: DirectoryWatcher::handle_watcher_event also processes watcher batches on the model context and canonicalizes paths while routing updates to repos/subscribers.
• crates/warp_util/src/standardized_path.rs: from_local_canonicalized performs filesystem canonicalization, which is I/O and can be expensive when repeated over large watcher batches.

Working hypothesis

Agent workflows often edit, generate, or delete many files in a project. If the project is watched by repo metadata / Project Explorer / code review machinery, those file changes can arrive as watcher batches and cause synchronous path canonicalization plus repo lookup on the main thread. That matches the provided stack and would explain intermittent full-window unresponsiveness during agent runs.

Duplicate check

I searched all open non-PR issues and recent closed issues. There are adjacent reports about agent hangs and Project Explorer/file-tree watcher behavior, but I did not find two or more existing issues with the same combination of agent-triggered full-app freeze plus this repo metadata watcher stack, so this should not be marked duplicate yet.

Follow-up needed

The new sample raises confidence, but maintainers still need the exact trigger and a fuller hang profile to reproduce and size the fix.

Question reasoning

1. What exact agent workflow most reliably triggers the freeze (for example: opening a Warp Agent, running a local/cloud agent, using Claude/Codex CLI, editing many files, or running a build)? — The stack suggests file-change processing is involved, but only the reporter can identify the agent type and action pattern that preceded the freeze.
2. Can you attach the full Activity Monitor sample or spindump captured while Warp is unresponsive, rather than only the excerpt pasted in the comment? — A longer profile would confirm whether the force-quit-level freeze remains in the repo metadata watcher path or later moves to another blocking call.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz