Feature request: Expose statusline geometry or allow fixed-height statusline for external shader integration

Summary

The statusline area dynamically resizes based on content, and there is no way to determine its pixel boundary or lock it to a fixed row count. This makes it impossible for external tools to reliably target the statusline region for visual rendering.

Problem

Ghostty (and potentially other GPU-capable terminals) supports custom GLSL post-processing shaders that operate on the terminal framebuffer. These shaders receive uniforms like iResolution and iTime, allowing per-pixel effects across the terminal surface.

We're building a project that uses this capability to render GPU-accelerated visual effects — animated gradients, glow, shimmer — specifically on the Claude Code statusline region. The goal is creative customization of the statusline beyond what ANSI escape sequences can achieve.

The problem is that the shader has no way to know which pixels belong to the statusline. Since Claude Code dynamically resizes the statusline area based on content, a hardcoded pixel offset from the bottom of the terminal inevitably drifts:

• The shader paints effects over the input/typing area
• Or the shader leaves gaps between the effect region and the actual statusline
• Every resize or content change breaks the alignment

The statusline command already receives structured JSON via stdin containing context_window, model, and workspace information. The geometry of the statusline region is the one missing piece needed to make external visual integrations work reliably.

Proposed Solutions

Either of these would solve the problem (both would be even better):

Option A: Config option to lock statusline height

A configuration option that fixes the statusline to a specific number of terminal rows:

{
  "statusLineRows": 4
}

When set, the statusline region would always occupy exactly that many rows, regardless of content length. Content that exceeds the space could truncate or scroll internally. This gives external tools a stable, predictable target region.

Option B: Expose statusline geometry in the statusline command's stdin JSON

Add fields to the JSON payload that the statusline command already receives:

{
  "context_window": { ... },
  "model": "...",
  "statusline_rows": 3,
  "statusline_y_offset": 42
}

Where:

• statusline_rows — current height of the statusline in terminal rows
• statusline_y_offset — row offset from the top of the terminal where the statusline begins

The statusline command could then write this information to a known file path (e.g., /tmp/claude-code-statusline-geometry) that an external shader can read.

Why This Matters

The statusline command is already a powerful extensibility point — it lets users replace the default status display with arbitrary programs. But visual customization is currently limited to what ANSI text rendering can do. Terminal GPU shaders open up a much richer design space (smooth gradients, particle effects, animated transitions), and the only barrier is knowing where the statusline actually is.

This is a niche use case, but the implementation cost for Option B is low — the geometry information already exists internally, it just needs to be included in the JSON payload that's already being serialized and sent to the statusline command.

Environment

• Terminal: Ghostty (with custom GLSL shader support)
• Claude Code: latest
• OS: Linux (COSMIC desktop)

Correct:
<img width="998" height="181" alt="Image" src="https://github.com/user-attachments/assets/a5c7455d-a816-472b-a2a1-98322266849a" />

Status dynamically shrank:
<img width="998" height="181" alt="Image" src="https://github.com/user-attachments/assets/a99ae511-b84f-4222-a1d1-065b0bc60411" />

Status dynamically grew:
<img width="998" height="181" alt="Image" src="https://github.com/user-attachments/assets/eba69471-ff82-4d96-a85b-e50c8398bd47" />