[Bug]: Bilibili ranking output is broken in KakuCLI

[Sure-Will]

Description

When I run opencli bilibili ranking inside KakuCLI on macOS, the output formatting becomes messy and hard to read.

The command itself returns data, but the rendered table/layout appears broken in KakuCLI, which makes the result inconvenient to view compared with a normal terminal.

Steps to Reproduce

1. Open KakuCLI on macOS
2. Run opencli bilibili ranking
3. Observe the rendered output

The command returns ranking data, but the table formatting is visually mixed up or not aligned properly in KakuCLI.

Expected Behavior

opencli bilibili ranking should render in a clean, readable format in KakuCLI, with properly aligned columns and predictable layout.

If the terminal does not fully support the default table renderer, OpenCLI should ideally fall back to a more robust plain or text-friendly format.

OpenCLI Version

1.6.8

Node.js Version

Node.js v25.8.2

Operating System

macOS

Logs / Screenshots

Command:

opencli bilibili ranking

Additional context:

• The issue happens specifically in KakuCLI
• Data is returned, but the rendered formatting is confusing and not easy to read
• As a workaround, machine-readable formats like -f json may still be easier to use

[Astro-Han]

I dug into this and reproduced the behavior locally.

What I found:

• #737 only falls back from table to yaml when process.stdout.isTTY is false
• That works in a true non-TTY case. I verified it with opencli@1.6.8: default output becomes YAML
• It does not work in PTY-based hosts. In a PTY session, stdout.isTTY is still true, so OpenCLI keeps using table
• I reproduced that too with opencli@1.6.8: same command outputs a table in PTY, but switches to YAML immediately with OUTPUT=yaml or -f yaml

So the problem is not that #737 is missing. The problem is that the current check is too narrow.

KakuCLI seems to be in the same bucket as Codex App, Codex CLI, and Claude Code: they can run commands in a pseudo-terminal, so isTTY is true, but the host renderer still does a poor job with box-drawing tables.

---

A couple things to add before writing the fix.

TERM=dumb alone probably won't cover KakuCLI. Most PTY-based hosts inherit the parent terminal's TERM value (usually xterm-256color), so the condition never fires. @Sure-Will could you run these inside KakuCLI and paste the output?

echo $TERM
node -e "console.log(process.stdout.columns)"

Looking at the screenshot again, the garbled output looks more like a width mismatch than missing box-drawing support. cli-table3 calculates layout from process.stdout.columns, but if KakuCLI's actual render area is narrower, every row wraps wrong.

Proposed fix (three parts, all small):

1. Extract a supportsRichTable() helper in src/output.ts:

   • process.stdout.isTTY is true
   • TERM is not empty or dumb
   • process.stdout.columns >= 60

2. Plug it into the existing auto-downgrade:

   else if (fmt === 'table' && !supportsRichTable()) fmt = 'yaml';

3. Document OUTPUT=yaml / OUTPUT=plain in README as the recommended config for AI agent hosts and embedded terminals.

The columns check is probably what fixes the actual KakuCLI bug. TERM check is cheap insurance for true dumb terminals. And documenting OUTPUT gives host developers a direct opt-in, so we're not playing whack-a-mole with every new PTY host.

Happy to take this if the direction works.

[Sure-Will]

I dug into this and reproduced the behavior locally.

What I found:

• #737 only falls back from table to yaml when process.stdout.isTTY is false
• That works in a true non-TTY case. I verified it with opencli@1.6.8: default output becomes YAML
• It does not work in PTY-based hosts. In a PTY session, stdout.isTTY is still true, so OpenCLI keeps using table
• I reproduced that too with opencli@1.6.8: same command outputs a table in PTY, but switches to YAML immediately with OUTPUT=yaml or -f yaml

So the problem is not that #737 is missing. The problem is that the current check is too narrow.

KakuCLI seems to be in the same bucket as Codex App, Codex CLI, and Claude Code: they can run commands in a pseudo-terminal, so isTTY is true, but the host renderer still does a poor job with box-drawing tables.

Suggested fix:

Instead of treating isTTY === true as “safe for table output”, detect whether the terminal actually supports rich table rendering.

A simple version would be:

• keep table only when stdout is a TTY and TERM is a real terminal value
• fall back to YAML when TERM is empty or dumb

In other words, replace the current check with something closer to supportsRichTableOutput() instead of process.stdout.isTTY alone.

That keeps the current behavior for normal terminals, but avoids broken table output in PTY-based agent hosts.

If that direction makes sense, I can open a follow-up PR with a minimal patch and tests.

Yes, KakuCLI seems to be exactly that kind of PTY-based host. Thanks for digging into it and reproducing the issue. That proposed direction makes sense to me.

[Sure-Will]

could you run these inside KakuCLI and paste the output

~ echo $TERM
node -e "console.log(process.stdout.columns)"
xterm-256color
140
~

this is my kaku cli's output

[Sure-Will]

I tested opencli bilibili ranking again just now, and there is still no change on my side.

The output is still rendered in the same broken / hard-to-read way in KakuCLI.

So I assume this is expected for now, since the proposed fix has not been implemented yet in the current released version.

[Astro-Han]

@Sure-Will Thanks for testing. TERM=xterm-256color and columns=140 confirms the PTY is reporting normal values, so the TERM/columns checks in the proposed fix won't help here. The rendering issue is on KakuCLI's side (likely font or layout).

For now, setting OUTPUT=yaml as an env var before calling opencli is the workaround. We'll still land the supportsRichTable() patch as a general improvement for other constrained terminals, and add docs about the OUTPUT env var.

[Sure-Will]

Thanks, that makes sense. Since KakuCLI reports normal TERM and columns values, I agree this specific issue is most likely on the KakuCLI rendering/layout side. For now, OUTPUT=yaml works as a reasonable workaround for me.