bug: cmdline_popup and inc_rename popups become permanently stuck and unresponsive

[av1155]

Did you check docs and existing issues?

• I have read all the noice.nvim docs
• I have updated the plugin to the latest version before submitting this issue
• I have searched the existing issues of noice.nvim
• I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

NVIM v0.11.4
Build type: Release
LuaJIT 2.1.1760617492

Operating system/version

macOS Sequoia 15.6 (Darwin 24.6.0)

Describe the bug

Noice popup windows (both cmdline_popup and inc_rename) occasionally become permanently stuck on screen after executing a command. When this happens:

1. The popup remains visible even after the command completes successfully (e.g., after :w saves the file, or after IncRename completes a successful rename)
2. The popup is completely unresponsive:
   • Cannot click on it to focus it
   • Pressing : does not bring up a new cmdline or focus the stuck popup
   • The popup displays "waiting for input" but accepts no input
3. The only solution is to fully close and reopen Neovim

This appears to be an orphaned floating window that Noice has lost track of. The window becomes "stuck" at the UI level and cannot be cleaned up or interacted with.

Affected popups:

• cmdline_popup (regular command line)
• inc_rename popup (from inc-rename.nvim integration via Noice preset)

Both exhibit identical symptoms, suggesting a common root cause in Noice's popup lifecycle management.

Steps To Reproduce

Note: This is an intermittent issue that happens "sometimes" during normal workflow. I have not been able to identify exact reproducible steps, but it occurs:

• After executing various cmdline commands (:w, :e, :bd, etc.)
• After using :IncRename to rename a symbol (popup gets stuck after successful rename)
• More frequently when using custom buffer management
• Possibly related to interactions with other floating windows (Neo-tree, Edgy)

Expected behavior: The popup should disappear after the command executes.

Actual behavior: The popup remains stuck on screen, completely unresponsive, requiring a full Neovim restart.

Minimal config

-- Noice config
require("noice").setup({
  cmdline = {
    enabled = true,
    view = "cmdline_popup",
    opts = {
      position = {
        row = "30%",
        col = "50%",
      },
    },
  },
  presets = {
    lsp_doc_border = true,
    -- inc_rename preset is NOT explicitly enabled, but inc-rename.nvim is installed
  },
  hover = {
    enabled = true,
    silent = false,
  },
  signature = {
    enabled = true,
    auto_open = {
      enabled = true,
    },
  },
  routes = {
    { filter = { event = "notify", find = "Content is not an image" }, opts = { skip = true } },
    {
      filter = {
        event = "notify",
        kind = "info",
        any = {
          { find = "^Updating registries" },
          { find = "^Successfully updated %d+ registr%w+%.?" },
          { find = "^Checking for package updates" },
          { find = "^No updates available" },
        },
      },
      opts = { skip = true },
    },
  },
})

Potentially related plugins

• inc-rename.nvim (7c79416330364976955ec8059fe3832b72ee1271) - LSP rename with popup (also gets stuck)
• edgy.nvim (541705c0e2d67c8925d1c072ac11d30a644ca6a7) - window management
• neo-tree.nvim (e1d464a45a2ff8328d3973e0f9737a81c3b42bf6) - floating file tree
• nui.nvim (de740991c12411b663994b2860f1a4fd0937c130)
• LazyVim (a65d5d530d372b39a468dfbb2ce633f344770c5c)

Also using a custom buffer close utility that might interact with this issue.

Additional context

I investigated the Noice source code and noticed that cmdline_popup has:

• focusable = false
• enter = false
• No explicit close event handlers by default

The inc_rename preset (lua/noice/config/preset.lua) also creates a popup with relative = "cursor" but no explicit close handlers.

Question: Would adding explicit close handlers help prevent this orphaning issue? For example:

cmdline = {
  enabled = true,
  view = "cmdline_popup",
  opts = {
    position = {
      row = "30%",
      col = "50%",
    },
    close = {
      events = { "CmdlineLeave" },
    },
  },
},

Or is this a deeper issue with the Nui popup lifecycle that needs to be addressed in Noice itself?

The fact that:

1. Multiple different popup types exhibit the same issue (cmdline_popup AND inc_rename)
2. The popups become completely unresponsive (can't even trigger a new cmdline with :)
3. The issue is intermittent

...suggests the window might be entering an invalid state that Noice/Nui can't recover from without a full restart. This could be a race condition in the popup unmount/cleanup logic.

Terminal

Ghostty
tmux-256color (Ghostty terminal under tmux)