Skip to content

fix: add --verbose flag for stream-json output format - #4

Closed
eYdr1en wants to merge 2 commits into
Ark0N:masterfrom
eYdr1en:fix/claude-cli-verbose-flag
Closed

fix: add --verbose flag for stream-json output format#4
eYdr1en wants to merge 2 commits into
Ark0N:masterfrom
eYdr1en:fix/claude-cli-verbose-flag

Conversation

@eYdr1en

Copy link
Copy Markdown

Problem

The Ralph Loop wizard (plan orchestrator) was failing with the error:

When using --print, --output-format=stream-json requires --verbose

Root Cause

Claude CLI v2.1.22+ changed its requirements - when using --print with --output-format=stream-json, the --verbose flag is now required.

Solution

Added --verbose flag to the runPrompt args in src/session.ts:

constargs=['-p','--dangerously-skip-permissions','--output-format','stream-json','--verbose',// Required for stream-json output format];

Testing

  • Tested Ralph Loop wizard - now starts successfully without the error
  • Verified with claude --help that --verbose is a valid flag

🤖 Generated with Claude Code

When COLORTERM=truecolor is inherited from the outer terminal (e.g., Ghostty),
Claude Code's Ink UI tries to use truecolor mode which xterm.js doesn't
handle correctly, causing rendering issues (gray/white backgrounds).
This fix unsets COLORTERM in all PTY spawns so applications use standard
256-color mode which xterm.js fully supports.
Fixes: xtermjs/xterm.js#484
Claude CLI v2.1.22+ now requires --verbose when using
--output-format=stream-json with -p/--print mode.
Without this flag, the CLI errors with:
"Error: When using --print, --output-format=stream-json requires --verbose"
This broke the Ralph Loop wizard and plan orchestrator agents.
@Ark0N

Copy link
Copy Markdown
Owner

Fixed in 50b1718 — --verbose flag added to runPrompt() CLI args for Claude CLI v2.1.22+ compatibility.

@Ark0NArk0N closed this Feb 18, 2026
michael-ltm pushed a commit to michael-ltm/Codeman that referenced this pull request Jul 4, 2026
- Ark0N#2: drop the "本机"/"(本机)" special-case labels in the fleet device
panel, device <select>, and welcome device row — show the real device
name (local = os.hostname()). A remote viewer sees the true machine name.
- Ark0N#4: persist closed fleet tabs to localStorage (codeman:fleet-hidden-tabs)
so a close survives reloads; prune keys whose session is gone (bounded
set); add a reopen path — clicking a device-panel session row calls
openFleetSessionTab() to unhide + selectSession.
- Ark0N#5: submitFleetCreateSession now opens + selects the new session as a tab
(mirrors _quickStartRemote) and toasts "已在 <设备名> 创建并打开".
Local (non-fleet) session close/behavior is byte-identical: the persistent
hidden set is fleet-key-only (isFleetKey/_looksLikeFleetKey guards), and
requestCloseSession still routes local keys to the confirm modal untouched.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
michael-ltm pushed a commit to michael-ltm/Codeman that referenced this pull request Jul 4, 2026
_pruneFleetHiddenKeys keyed off sessionTabs, which the central builds only
from live remoteHandles — so an OFFLINE device (sleep/wifi-blip/node-restart)
drops all its still-running tmux sessions from sessionTabs. The prune then
wiped those sessions' persistent hidden markers, and on reconnect the closed
tab silently reappeared, defeating Ark0N#4 "关闭持久记住,刷新不再出现".
Gate the prune on the owning device: for each hidden ${deviceId}:${sessionId},
keep the marker whenever the device is absent or status !== 'online' (absence
isn't a positive "gone" signal when offline/unknown, incl. the first snapshot
before a device reconnects); only prune when the device is online AND the
session is genuinely absent from its live list. refreshFleetState passes its
existing online map. Truly-stopped sessions (device online, session deleted)
are still pruned, so the set stays bounded.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@eYdr1en@Ark0N