bug: When using prompts first time, randomly custom prompts do not go to AI CLI tool

[Racle]

Did you check docs and existing issues?

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

Neovim version (nvim -v)

NVIM v0.12.0-dev-1245+g63ece2b151

Operating system/version

Pop_OS 22.04

Describe the bug

When using custom prompts AND opening AI tool for the first time, prompt is added to top of CLI tool instead to its input box.
It doesn't happen all the time, but most of the times.

IF AI Cli tool is already open, it seems to be working just fine.

Steps To Reproduce

1. Set custom prompts in config + tmux (or use provided repro.lua)

2. Select prompt

3. Select CLI tool

4. Prompt is in wrong place

Same issue with Repro with my config

Expected Behavior

Prompts should go to AI CLI Tool

Repro

vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()

require("lazy.minit").repro(
  {
    spec = {
      {
        "folke/sidekick.nvim",
        opts = {
          -- add any options here
          cli = {
            mux = {
              backend = "tmux",
              enabled = true
            },
            prompts = {
              commit = "Create one line git commit message\nUse conventional commits.\nCopy it to clipboard.\nUse printf to print message.",
              commit_stashed = "Create one line git commit message for stashed files\nUse conventional commits.\nCopy it to clipboard.\nUse printf to print message.\nif no changes, reply with 'No changes to commit'.",
              security = "Review {file} for security vulnerabilities"
            }
          }
        }
        -- add any other plugins here
      }
    }
  }
)

[folke]

That;'s not a bug and also not possible to fix.

If your cli tool takes a lot of time to initialize, it will not process the first message.

There is a delay to accomodate for this, but it may not be enough for your system, or that tool

[folke]

I just increased it from 500ms to 2s, but it may still not be enough

[Racle]

@folke can the initial delay be adjustable by user?

It would be nice to change initial delay based on my needs/system delays I have.
But 2s delay might be okay for now.

[folke]

ok, that's a good idea. Even better to make it per tool. Will add

[folke]

Solution Implemented

The issue was that CLI tools like Claude CLI or Gemini CLI need time to initialize and render their UI before they start capturing stdin. If text is sent too early, it appears in the terminal buffer but not in the tool's input box.

New Terminal Readiness Detection

The terminal backend now uses an adaptive readiness detection mechanism instead of a fixed delay:

1. Poll terminal output every 100ms to check if the CLI tool has rendered its interface
2. Wait for initial output - The tool must produce at least 5 lines (indicating the UI has rendered)
3. Wait for output to stabilize - Once output appears, wait 500ms with no new lines (indicating initialization is complete)
4. Cursor position check - Cursor must be past line 3 (indicating the tool is in a ready state)
5. Timeout safety - If none of these conditions are met after 5 seconds, proceed anyway

This approach typically reduces the wait time from 2000ms to ~600ms for most CLI tools, while being reliable enough to handle slower tools that need more initialization time.

The key insight is that we're not waiting for the terminal to be ready, but for the program itself to be ready to accept input.

---

*~ Claude*