[FEATURE] Configurable output collapse threshold (number of visible lines before "+N lines" collapse)

Resolved 💬 3 comments Opened Nov 27, 2025 by ankushdixit Closed Dec 1, 2025

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

When running bash commands or slash commands, Claude Code only shows 3-4 lines of output before collapsing the rest with "+N lines (ctrl+o to expand)".

For workflows involving custom CLI tools, different commands have different visibility needs:

  • sk work-list shows a summary + list items - needs ~12 visible lines
  • sk start generates a detailed briefing - needs ~20 visible lines
  • git status typically needs ~5 lines
  • npm test might need ~15 lines to show test results

Currently there's no way to configure this, forcing users to manually expand output (ctrl+o) on every command, which interrupts workflow significantly when running frequent commands.

Example of the problem:
⏺ Bash(sk work-list)
⎿ Work Items (3 total, 0 in progress, 3 not started)
🟠 HIGH
… +11 lines (ctrl+o to expand)

The actual work items I need to see are hidden every time.

Proposed Solution

Add configurable output collapse thresholds with per-command granularity.

In settings.json or .claude/settings.json:

{
"terminal": {
"outputCollapseThreshold": 10, // global default
"commandThresholds": {
"sk work-list": 15,
"sk start": 25,
"sk status": 20,
"git status": 8,
"npm test": 20,
"pytest": 25
}
}
}

Matching behavior:

  • Exact match first: "sk work-list" matches sk work-list
  • Prefix match: "sk" would match all sk commands as fallback
  • Glob patterns: "npm *" matches npm install, npm test, etc.
  • Fall back to global default if no match

A threshold of 0 could mean "never collapse" for that command.

This gives users full control over their workflow while keeping sensible defaults for everyone else.

Alternative Solutions

_No response_

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

Example scenario - Session-Driven Development workflow:

  1. I run sk work-list to see my pending tasks

→ Only see 3 lines, missing the actual task list
→ Press ctrl+o to expand

  1. I run sk start feature_xyz to begin a session

→ Only see 3 lines of a 200+ line briefing
→ Press ctrl+o to expand to read the context

  1. I run sk status to check progress mid-session

→ Only see header, miss the status details
→ Press ctrl+o again

  1. After each command, I run sk work-next to see recommendations

→ Same collapse behavior, another ctrl+o

In a typical 30-minute session, I press ctrl+o 15-20 times just to see my own CLI output. With per-command thresholds, I could configure:

  • sk work-list: 15 lines (shows full task list)
  • sk start: 30 lines (shows key briefing sections)
  • sk status: 12 lines (shows complete status)

This would eliminate repetitive manual expansion for frequently-used commands while keeping the clean collapsed UI for verbose/noisy commands.

Additional Context

Technical consideration:
The matching logic could follow precedent from .gitignore or ESLint overrides - exact match → prefix match → glob → default.

Related issues:

  • #2963 addressed showing last lines (implemented), but doesn't solve the threshold configuration
  • #3412 requests similar configurability for pasted text blocks

Alternative approaches considered:

  1. CLI tools could output ANSI codes to hint at collapse behavior (more complex)
  2. Per-tool-type defaults (Bash vs Read vs MCP) - less flexible than per-command

User impact:
Anyone using custom CLI tooling, project management commands, or verbose test runners would benefit. The current 3-4 line default optimizes for simple commands but penalizes power users with custom workflows.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗