respect unix pipes

[rxgrant]

Don't stop for tty input when in a pipe.
Also offer an option --no-input or similar.

[JeanMertz]

There are a couple of RFDs that go into this topic:

• https://jp.computer/rfd/048-four-channel-output-model (implemented)
• https://jp.computer/rfd/049-non-interactive-mode-and-detached-prompt-policy (pending)

And not exactly on this topic, but related: https://jp.computer/rfd/050-scripting-ergonomics-for-conversation-management

---

Don't stop for tty input when in a pipe.

This is a deliberate choice. This is similar to how e.g. git works: having a pipe on stdin does not mean we can't show a prompt for user input, so we don't limit JP in that situation. We still (will) have flags that allow you to force JP not to show prompts, but e.g. sending a query over stdin f.e. should not prevent you from being able to approve/deny tool runs.

[rxgrant]

I think the distinction is that sometimes, when JP stops, it has been backgrounded or has output redirected (but not input). It takes a lot of system knowledge to suspect that a command in a pipe is stopped for input.

[JeanMertz]

Even if output is redirected, prompts still work as expected (they use /dev/tty instead of stdin/stdout). But yes, if JP runs in an unattended situation, then we don't want JP to be blocked in the background, that is what the above RFDs tackle.

RFD 049 states:

This RFD introduces a configurable detached prompt policy that controls what happens when an inquiry arrives and no interactive client is available

That is exactly the situation when /dev/tty is unavailable.

See the "Design" section of that RFD to understand how this would work once implemented, but the gist is that non-interactive mode errors on inqueries, unless explicitly opted-in to auto-approving.

This one is also relevant (longer term): https://jp.computer/rfd/027-client-server-query-architecture

[rxgrant]

RFD 049 sounds like a great fix. I think the future is going to be even more about situational awareness of complex systems than it is today (see also #675).