tmux capture-pane -ep returns only what the running program actually wrote: typically foreground colors and trimmed trailing whitespace. It does not synthesize a background, and it does not pad cells. To produce a rectangular block with a consistent background (for example, matching Neovim’s Normal highlight), you have to wrap and pad every line yourself with explicit truecolor bg sequences and re-apply the background after any embedded \e[0m or \e[49m.
The intuition “capture-pane gives me what I see” is wrong in two directions. First, programs like Claude Code set foreground color but leave background to whatever the terminal’s default is; empty cells arrive with no ANSI at all and render as whichever surrounding tool’s default bg (fzf, another terminal), which looks washed-out and dull. Second, trailing whitespace is stripped, so a “full-width” pane capture of a 210-column pane with a 40-column status line arrives as a 40-character string for that row. Any downstream renderer that expects a rectangular block has to reconstruct both the width and the background.
The repair pattern: for each captured line, emit \e[48;2;R;G;Bm + content + space-padding to target width + \e[0m, and after any embedded \e[0m or \e[49m inside the content, re-apply the bg prefix so the rest of the line keeps painting. The reset escape doesn’t undo your wrapper; it cancels everything until you re-set, which is what \e[49m (default-background) explicitly does.
Any tool that embeds tmux-captured content inside another ANSI renderer (fzf, a second tmux pane, an external pager) needs to own the background and width, not delegate them to the surrounding renderer. When the source is Neovim, query Neovim for its Normal bg (not the terminal’s default) so the capture integrates visually with what the user actually sees. See Neovim Window Geometry and Read-Only RPC for the cropping pre-step, and Fzf Preview and Popup Control for the most common consumer of wrapped capture output.