fix(query): make openkb query safe for non-TTY stdout (closes #34)

[Litash]

prompt_toolkit's print_formatted_text constructs a Win32Output on Windows that demands a real console handle, crashing run_query (stream=True) with NoConsoleScreenBufferError when stdout is a pipe, file, or captured subprocess stream (MCP stdio, redirected output, CI captures).

Two complementary changes:

1. Defensive: push the existing _use_color() gate into the _fmt helper in openkb/agent/chat.py so every prompt_toolkit call site -- chat REPL, query streaming, slash-command output -- falls back to plain sys.stdout.write when the output isn't a usable console.

2. UX: auto-disable stream=True in openkb query for non-TTY stdout via a small _stream_to_tty() helper in openkb/cli.py. Non-interactive callers now reach the clean stream=False branch in run_query and get the final answer string instead of an interleave of tool-call lines and answer tokens. The non-stream branch echoes the answer so output is preserved.

[KylinMountain]

Reviewed. The fix matches the #34 diagnosis end-to-end and the two-layer defense is the right shape: _fmt's plain-text fallback covers any path that still reaches print_formatted_text, while _stream_to_tty() keeps non-interactive callers out of the stream branch entirely. --save continues to work in both modes because run_query returns the answer string either way.

One small observation, not blocking:

The two TestQueryStreamGate tests patch openkb.agent.query.run_query, which works only because cli.py does from openkb.agent.query import run_query lazily inside the query command. If anyone ever hoists that import to module scope, the patch silently misses (cli binds run_query as a local name and the source-module patch doesn't touch it), and both tests would pass without exercising the new code. Worth either patching openkb.cli.run_query instead, or adding a brief comment so the next refactor doesn't quietly break the coverage.

Otherwise LGTM — clean fix, good test discipline (the _boom mock that raises on misuse is a nice touch).

[KylinMountain]

LGTM

[Litash]

prompt_toolkit's print_formatted_text constructs a Win32Output on Windows that demands a real console handle, crashing run_query (stream=True) with NoConsoleScreenBufferError when stdout is a pipe, file, or captured subprocess stream (MCP stdio, redirected output, CI captures).

Two complementary changes:

1. Defensive: push the existing _use_color() gate into the _fmt helper in openkb/agent/chat.py so every prompt_toolkit call site -- chat REPL, query streaming, slash-command output -- falls back to plain sys.stdout.write when the output isn't a usable console.

2. UX: auto-disable stream=True in openkb query for non-TTY stdout via a small _stream_to_tty() helper in openkb/cli.py. Non-interactive callers now reach the clean stream=False branch in run_query and get the final answer string instead of an interleave of tool-call lines and answer tokens. The non-stream branch echoes the answer so output is preserved.

[KylinMountain]

Reviewed. The fix matches the #34 diagnosis end-to-end and the two-layer defense is the right shape: _fmt's plain-text fallback covers any path that still reaches print_formatted_text, while _stream_to_tty() keeps non-interactive callers out of the stream branch entirely. --save continues to work in both modes because run_query returns the answer string either way.

One small observation, not blocking:

The two TestQueryStreamGate tests patch openkb.agent.query.run_query, which works only because cli.py does from openkb.agent.query import run_query lazily inside the query command. If anyone ever hoists that import to module scope, the patch silently misses (cli binds run_query as a local name and the source-module patch doesn't touch it), and both tests would pass without exercising the new code. Worth either patching openkb.cli.run_query instead, or adding a brief comment so the next refactor doesn't quietly break the coverage.

Otherwise LGTM — clean fix, good test discipline (the _boom mock that raises on misuse is a nice touch).

[KylinMountain]

LGTM

[Litash]

prompt_toolkit's print_formatted_text constructs a Win32Output on Windows that demands a real console handle, crashing run_query (stream=True) with NoConsoleScreenBufferError when stdout is a pipe, file, or captured subprocess stream (MCP stdio, redirected output, CI captures).

Two complementary changes:

1. Defensive: push the existing _use_color() gate into the _fmt helper in openkb/agent/chat.py so every prompt_toolkit call site -- chat REPL, query streaming, slash-command output -- falls back to plain sys.stdout.write when the output isn't a usable console.

2. UX: auto-disable stream=True in openkb query for non-TTY stdout via a small _stream_to_tty() helper in openkb/cli.py. Non-interactive callers now reach the clean stream=False branch in run_query and get the final answer string instead of an interleave of tool-call lines and answer tokens. The non-stream branch echoes the answer so output is preserved.

[KylinMountain]

Reviewed. The fix matches the #34 diagnosis end-to-end and the two-layer defense is the right shape: _fmt's plain-text fallback covers any path that still reaches print_formatted_text, while _stream_to_tty() keeps non-interactive callers out of the stream branch entirely. --save continues to work in both modes because run_query returns the answer string either way.

One small observation, not blocking:

The two TestQueryStreamGate tests patch openkb.agent.query.run_query, which works only because cli.py does from openkb.agent.query import run_query lazily inside the query command. If anyone ever hoists that import to module scope, the patch silently misses (cli binds run_query as a local name and the source-module patch doesn't touch it), and both tests would pass without exercising the new code. Worth either patching openkb.cli.run_query instead, or adding a brief comment so the next refactor doesn't quietly break the coverage.

Otherwise LGTM — clean fix, good test discipline (the _boom mock that raises on misuse is a nice touch).

[KylinMountain]

LGTM

[Litash]

prompt_toolkit's print_formatted_text constructs a Win32Output on Windows that demands a real console handle, crashing run_query (stream=True) with NoConsoleScreenBufferError when stdout is a pipe, file, or captured subprocess stream (MCP stdio, redirected output, CI captures).

Two complementary changes:

1. Defensive: push the existing _use_color() gate into the _fmt helper in openkb/agent/chat.py so every prompt_toolkit call site -- chat REPL, query streaming, slash-command output -- falls back to plain sys.stdout.write when the output isn't a usable console.

2. UX: auto-disable stream=True in openkb query for non-TTY stdout via a small _stream_to_tty() helper in openkb/cli.py. Non-interactive callers now reach the clean stream=False branch in run_query and get the final answer string instead of an interleave of tool-call lines and answer tokens. The non-stream branch echoes the answer so output is preserved.

[KylinMountain]

Reviewed. The fix matches the #34 diagnosis end-to-end and the two-layer defense is the right shape: _fmt's plain-text fallback covers any path that still reaches print_formatted_text, while _stream_to_tty() keeps non-interactive callers out of the stream branch entirely. --save continues to work in both modes because run_query returns the answer string either way.

One small observation, not blocking:

The two TestQueryStreamGate tests patch openkb.agent.query.run_query, which works only because cli.py does from openkb.agent.query import run_query lazily inside the query command. If anyone ever hoists that import to module scope, the patch silently misses (cli binds run_query as a local name and the source-module patch doesn't touch it), and both tests would pass without exercising the new code. Worth either patching openkb.cli.run_query instead, or adding a brief comment so the next refactor doesn't quietly break the coverage.

Otherwise LGTM — clean fix, good test discipline (the _boom mock that raises on misuse is a nice touch).

[KylinMountain]

LGTM

[Litash]

prompt_toolkit's print_formatted_text constructs a Win32Output on Windows that demands a real console handle, crashing run_query (stream=True) with NoConsoleScreenBufferError when stdout is a pipe, file, or captured subprocess stream (MCP stdio, redirected output, CI captures).

Two complementary changes:

1. Defensive: push the existing _use_color() gate into the _fmt helper in openkb/agent/chat.py so every prompt_toolkit call site -- chat REPL, query streaming, slash-command output -- falls back to plain sys.stdout.write when the output isn't a usable console.

2. UX: auto-disable stream=True in openkb query for non-TTY stdout via a small _stream_to_tty() helper in openkb/cli.py. Non-interactive callers now reach the clean stream=False branch in run_query and get the final answer string instead of an interleave of tool-call lines and answer tokens. The non-stream branch echoes the answer so output is preserved.

[KylinMountain]

Reviewed. The fix matches the #34 diagnosis end-to-end and the two-layer defense is the right shape: _fmt's plain-text fallback covers any path that still reaches print_formatted_text, while _stream_to_tty() keeps non-interactive callers out of the stream branch entirely. --save continues to work in both modes because run_query returns the answer string either way.

One small observation, not blocking:

The two TestQueryStreamGate tests patch openkb.agent.query.run_query, which works only because cli.py does from openkb.agent.query import run_query lazily inside the query command. If anyone ever hoists that import to module scope, the patch silently misses (cli binds run_query as a local name and the source-module patch doesn't touch it), and both tests would pass without exercising the new code. Worth either patching openkb.cli.run_query instead, or adding a brief comment so the next refactor doesn't quietly break the coverage.

Otherwise LGTM — clean fix, good test discipline (the _boom mock that raises on misuse is a nice touch).

[KylinMountain]

LGTM

[Litash]

prompt_toolkit's print_formatted_text constructs a Win32Output on Windows that demands a real console handle, crashing run_query (stream=True) with NoConsoleScreenBufferError when stdout is a pipe, file, or captured subprocess stream (MCP stdio, redirected output, CI captures).

Two complementary changes:

1. Defensive: push the existing _use_color() gate into the _fmt helper in openkb/agent/chat.py so every prompt_toolkit call site -- chat REPL, query streaming, slash-command output -- falls back to plain sys.stdout.write when the output isn't a usable console.

2. UX: auto-disable stream=True in openkb query for non-TTY stdout via a small _stream_to_tty() helper in openkb/cli.py. Non-interactive callers now reach the clean stream=False branch in run_query and get the final answer string instead of an interleave of tool-call lines and answer tokens. The non-stream branch echoes the answer so output is preserved.

[KylinMountain]

Reviewed. The fix matches the #34 diagnosis end-to-end and the two-layer defense is the right shape: _fmt's plain-text fallback covers any path that still reaches print_formatted_text, while _stream_to_tty() keeps non-interactive callers out of the stream branch entirely. --save continues to work in both modes because run_query returns the answer string either way.

One small observation, not blocking:

The two TestQueryStreamGate tests patch openkb.agent.query.run_query, which works only because cli.py does from openkb.agent.query import run_query lazily inside the query command. If anyone ever hoists that import to module scope, the patch silently misses (cli binds run_query as a local name and the source-module patch doesn't touch it), and both tests would pass without exercising the new code. Worth either patching openkb.cli.run_query instead, or adding a brief comment so the next refactor doesn't quietly break the coverage.

Otherwise LGTM — clean fix, good test discipline (the _boom mock that raises on misuse is a nice touch).

[KylinMountain]

LGTM

[Litash]

prompt_toolkit's print_formatted_text constructs a Win32Output on Windows that demands a real console handle, crashing run_query (stream=True) with NoConsoleScreenBufferError when stdout is a pipe, file, or captured subprocess stream (MCP stdio, redirected output, CI captures).

Two complementary changes:

1. Defensive: push the existing _use_color() gate into the _fmt helper in openkb/agent/chat.py so every prompt_toolkit call site -- chat REPL, query streaming, slash-command output -- falls back to plain sys.stdout.write when the output isn't a usable console.

2. UX: auto-disable stream=True in openkb query for non-TTY stdout via a small _stream_to_tty() helper in openkb/cli.py. Non-interactive callers now reach the clean stream=False branch in run_query and get the final answer string instead of an interleave of tool-call lines and answer tokens. The non-stream branch echoes the answer so output is preserved.

[KylinMountain]

Reviewed. The fix matches the #34 diagnosis end-to-end and the two-layer defense is the right shape: _fmt's plain-text fallback covers any path that still reaches print_formatted_text, while _stream_to_tty() keeps non-interactive callers out of the stream branch entirely. --save continues to work in both modes because run_query returns the answer string either way.

One small observation, not blocking:

The two TestQueryStreamGate tests patch openkb.agent.query.run_query, which works only because cli.py does from openkb.agent.query import run_query lazily inside the query command. If anyone ever hoists that import to module scope, the patch silently misses (cli binds run_query as a local name and the source-module patch doesn't touch it), and both tests would pass without exercising the new code. Worth either patching openkb.cli.run_query instead, or adding a brief comment so the next refactor doesn't quietly break the coverage.

Otherwise LGTM — clean fix, good test discipline (the _boom mock that raises on misuse is a nice touch).

[KylinMountain]

LGTM

[Litash]

prompt_toolkit's print_formatted_text constructs a Win32Output on Windows that demands a real console handle, crashing run_query (stream=True) with NoConsoleScreenBufferError when stdout is a pipe, file, or captured subprocess stream (MCP stdio, redirected output, CI captures).

Two complementary changes:

1. Defensive: push the existing _use_color() gate into the _fmt helper in openkb/agent/chat.py so every prompt_toolkit call site -- chat REPL, query streaming, slash-command output -- falls back to plain sys.stdout.write when the output isn't a usable console.

2. UX: auto-disable stream=True in openkb query for non-TTY stdout via a small _stream_to_tty() helper in openkb/cli.py. Non-interactive callers now reach the clean stream=False branch in run_query and get the final answer string instead of an interleave of tool-call lines and answer tokens. The non-stream branch echoes the answer so output is preserved.

[KylinMountain]

Reviewed. The fix matches the #34 diagnosis end-to-end and the two-layer defense is the right shape: _fmt's plain-text fallback covers any path that still reaches print_formatted_text, while _stream_to_tty() keeps non-interactive callers out of the stream branch entirely. --save continues to work in both modes because run_query returns the answer string either way.

One small observation, not blocking:

The two TestQueryStreamGate tests patch openkb.agent.query.run_query, which works only because cli.py does from openkb.agent.query import run_query lazily inside the query command. If anyone ever hoists that import to module scope, the patch silently misses (cli binds run_query as a local name and the source-module patch doesn't touch it), and both tests would pass without exercising the new code. Worth either patching openkb.cli.run_query instead, or adding a brief comment so the next refactor doesn't quietly break the coverage.

Otherwise LGTM — clean fix, good test discipline (the _boom mock that raises on misuse is a nice touch).

[KylinMountain]

LGTM