[Bug] Global --no-color flag is a no-op for all commands

[404-Page-Found]

Summary

The global --no-color option is registered on the root command but is still not consumed by the main CLI. Current command output continues to use picocolors without honoring the flag.

The issue was previously closed as not planned, but the same behavior remains in current main.

Location

• src/index.ts — .option('--no-color', 'Disable colored output')
• src/commands/completion.ts — the only current consumer checks argv directly for completion and help generation

Steps to Reproduce

1. Run commit-echo --no-color suggest in a color-capable terminal.
2. Capture stdout and stderr.
3. Inspect the output for ANSI escape sequences.

Expected Behavior

--no-color should disable ANSI styling across all CLI commands.

Actual Behavior

The flag is parsed by Commander but does not change the global picocolors behavior, so commands such as suggest, history, init, and batch can still emit color sequences.

Suggested Fix

After parsing the root options, wire program.opts().noColor into the global color configuration and add end-to-end coverage across representative commands.

Impact

Plain-output users, CI and log consumers, and scripts that explicitly request --no-color still receive terminal escape sequences. The CLI global output-control flag is therefore unreliable.

Reviewed again against current main at 131c914195ec863197197eec024558012c03240d659 on September 25, 2026.

[404-Page-Found]

Triage update:

I checked the current main implementation and the dependency versions in the lockfile.

• src/index.ts registers --no-color, but does not need to consume the Commander option explicitly for the current implementation.
• The project resolves picocolors@1.1.1. That version checks process.argv.includes('--no-color') when it initializes color support, so commit-echo --no-color ... is already enough to disable pc.* formatting.
• The repository's historical PR fix: add no-color CLI flag #96 intentionally relied on this picocolors behavior; its tests exercise --no-color with forced color enabled.
• The issue's proposed program.opts().noColor check is also not the right Commander property for a negated option; --no-color maps to the color option.
• The completion command's explicit argv scan is separate logic for its custom help/error rendering.

Based on the current dependency behavior, #263 does not appear reproducible as described on main. I recommend leaving this open only if there is a concrete environment/reproduction showing ANSI escapes with --no-color; otherwise it can be closed as stale/not reproducible.