Skip to content

[travsr-cli] Fix #777: refuse travsr mcp on a terminal instead of hanging - #803

Open
ritikpal1122 wants to merge 1 commit into
Travsr-com:masterfrom
ritikpal1122:fix/777-mcp-tty-guard
Open

[travsr-cli] Fix #777: refuse travsr mcp on a terminal instead of hanging#803
ritikpal1122 wants to merge 1 commit into
Travsr-com:masterfrom
ritikpal1122:fix/777-mcp-tty-guard

Conversation

@ritikpal1122

Copy link
Copy Markdown
Collaborator

Closes #777.

travsr mcp speaks JSON-RPC over stdin, so run directly in a terminal it blocked on a request that is never typed: no output, no prompt, no indication anything was wrong. The report describes a process that "appears frozen".

$ travsr mcp
error: travsr mcp speaks JSON-RPC over stdin and is meant to be launched by an
MCP client, not run directly.
stdin is a terminal here, so there is no client to talk to and the server would
wait forever for a request that never arrives.

To connect it to your editor or agent: travsr connect
To drive the protocol by hand: TRAVSR_MCP_ALLOW_TTY=1 travsr mcp

Two decisions worth calling out

Guarded on stdin, not stdout. A client that pipes stdin while leaving stderr on the terminal is a normal working setup, so testing stdout would refuse a legitimate launch. stdin being a terminal is the condition that actually makes the server unusable, because there is no client on the other end to send a request.

TRAVSR_MCP_ALLOW_TTY keeps the escape hatch. Pasting a frame by hand to probe a response is a real debugging workflow, and a guard with no override would remove it.

Verified against the built binary, not only the unit test

All three paths, because the failure mode here is behavioural:

TTY               -> refuses and exits (was: hangs forever)
piped stdin       -> {"id":1,...,"serverInfo":{"name":"travsr","version":"1.0.0"}}
ALLOW_TTY=1 + TTY -> serves, no refusal

The middle one matters most: it is the regression this guard could plausibly cause, and it does not.

On the test

It asserts the wording, not the TTY branch. Faking a terminal on stdin is not portable, and the branch itself is a single is_terminal call. What can regress silently is the message, and the entire point of the issue is that the user was left with nothing to act on, so a message that stopped naming travsr connect or the override would reintroduce the dead end in a quieter form.

Verification

cargo test -p travsr-cli --bin travsr                     252 passed, 0 failed
cargo clippy -p travsr-cli --all-targets -- -D warnings   clean
cargo fmt --all -- --check                                clean
check-em-dash.sh                                          OK

One file changed.

…stead of hanging

`travsr mcp` speaks JSON-RPC over stdin, so run directly in a terminal it
blocked on a request that is never typed: no output, no prompt, no indication
anything was wrong. The reported experience was a process that "appears
frozen".

Guarded on stdin rather than stdout. A client that pipes stdin while leaving
stderr on the terminal is a normal working setup, so testing stdout would
refuse a legitimate launch. stdin being a terminal is the condition that makes
the server unusable, because there is no client on the other end to send a
request.

TRAVSR_MCP_ALLOW_TTY keeps the escape hatch for driving the protocol by hand,
which is a real debugging workflow the guard would otherwise remove.

The message names the transport, why nothing happened, and both ways forward.
An error that only said "not a tty" would reproduce the same dead end faster.

Verified all three paths against the built binary rather than only the unit
test: a TTY refuses and exits, piped stdin still serves a real initialize
response, and the override serves on a TTY. The test asserts the wording,
since faking a terminal is not portable and the branch itself is one call,
while the wording is what can regress silently.
@ritikpal1122
ritikpal1122 requested a review from raj-rkv as a code owner August 27, 2026 06:52
Sign up for free to 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.

bug: travsr mcp hangs indefinitely with no output when run in interactive terminal

1 participant