Tried to render share modal without a model fires in a ~10-min render loop (up to 84/sec)

[aqeelat]

Describe the bug

Warp logs Tried to render share modal without a model in a tight render loop. In ~/Library/Logs/warp.log I see 9,362 occurrences in ~25 hours of normal use, with bursts of up to 84 in a single second on a steady ~10-minute cadence (e.g. 07:00, 07:52, 08:14, 08:24, 08:35, 09:10, 09:18, 09:29, 09:51, 10:02). The regular spacing indicates a periodic background timer triggering a repaint storm while the modal view has no model.

To reproduce

1. Use Warp normally (I had TUI apps / agent sessions running in panes).
2. Inspect ~/Library/Logs/warp.log for the line:

   [WARN] Tried to render share modal without a model
   

3. Observe it repeating in bursts (~84/sec) roughly every ~10 minutes.

Reproduces on a fresh boot / clean log (not a function of long uptime), in stable v0.2026.07.08.17.54.stable_02, and the warn is still present on current master.

Expected behavior

The ShareBlockModal view should not remain mounted and re-rendering once its model is None; at minimum it should not emit a warn! on every repaint.

Root cause / additional context

app/src/terminal/share_block_modal.rs, in render_modal() (present unchanged on master):

let single_block = match &self.model {
    Some(model) => { /* ... */ }
    None => {
        log::warn!("Tried to render share modal without a model");
        Empty::new().finish()
    }
};

The ShareBlockModal view lives at the PaneGroup level and its model is Option because terminal models are session-specific. Nothing removes the view from the tree when the model is absent, so it re-renders Empty and warns on every repaint. I do not use Warp Drive or session sharing, yet the loop still fires.

Suggested fix: don't mount/retain the modal view when model is None, or short-circuit rendering without the per-frame warn (rate-limit / move to debug!).

Screenshots, videos, and logs

Log signature (counts from one ~25h rotation): 9,362 hits; top per-second bursts all ~84. Happy to attach a redacted log excerpt on request.

Operating system (OS)

macOS

Operating system and version

macOS 15.7.7 (build 24G720); Apple M3 Pro / 36 GB

Shell Version

zsh 5.9

Current Warp version

v0.2026.07.08.17.54.stable_02

Regression

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

Does this block you from using Warp daily?

No (but it causes noticeable UI stalls during each burst)

Is this an issue only in Warp?

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

Pre-submit Checks

• I searched Warp bugs and there are no duplicates
• I searched the Warp known issues page and this is not there

[oz-for-oss]

@aqeelat

Here's what I found while triaging this issue:

The warning is still present in the current code and is emitted during rendering, so a stuck share-block modal state would re-log it on every repaint. The report has enough version, OS, and log-count evidence for initial routing.

Maintainer details

I concluded that share-block modal rendering can repeatedly warn when the pane-group-level modal is rendered without an attached terminal model, producing log floods and UI stalls during repaint bursts..

Initial triage

This looks like a valid bug report for the share-block modal render path, with a secondary performance/log-flood symptom. The reporter provided a specific Warp stable version, macOS version, exact warning string, recurrence/count data, and noted visible stalls during the bursts.

Code inspection supports the reported warning path:

• app/src/terminal/share_block_modal.rs renders Empty and logs Tried to render share modal without a model whenever ShareBlockModal::render_modal() runs with self.model == None. Because this is inside render, any repaint while in that state can emit another warning.
• app/src/pane_group/mod.rs creates one pane-group-level ShareBlockModal with model: None and renders it whenever terminal_with_open_share_block_modal is set.
• app/src/pane_group/pane/terminal_pane.rs handles Event::ShareModalOpened by setting terminal_with_open_share_block_modal before conditionally updating the modal with the terminal model. A stale/open modal flag without a successful model update is therefore a plausible way to render the modal without a model.
• app/src/terminal/view.rs emits Event::ShareModalOpened from the terminal block share action after auth gating.

The reporter's proposed fix direction is plausible, but the exact trigger for the ~10-minute repaint cadence is not confirmed from the share-modal code alone. A likely implementation investigation would be to ensure the pane-group open flag is only set after the model update succeeds, clear/reset the modal model on close where appropriate, and avoid per-render warn logging for an expected empty state.

Duplicate check: exact warning-string matches exist in older issue logs, but those issues primarily report startup/blank-window/GPU failures rather than this share-modal render-loop/log-flood symptom, so I did not mark this as a duplicate.

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

Powered by Oz

[aqeelat]

Cross-linking #13758 — a related symptom where Hoverable floods the log with synthetic MouseMoved events. Both suggest excess re-rendering/event-synthesis under load; filed separately because the patterns differ (this one is bursty ~84/sec every ~10 min; #13758 is continuous).

[seemeroland]

It's unexpected to be attempting to render the ShareBlockModal if the share block modal is not open, which sounds like is what's happening. The right fix is to find out why it's being rendered and prevent that rather than remove the warning log.

[oz-for-oss]

This issue has been labeled ready-to-implement and is open for contributions involving code changes. If you'd like to tackle it, feel free to open a pull request against this issue. You can also comment @oz-agent on this issue to have the bot draft an implementation PR automatically.