anomalyco / anomalyco/opencode

[FEATURE]: let opencode run ignore an unused inherited stdin pipe

Open
#42,064 2 comments 2 reactions 1 assignee View on GitHub

@rekram1-node is already working on this.

Since Aug 12, 2026.

Dominant language
TypeScript
Stars
209k
Forks
27.5k
PR merge metrics
PR metrics pending

Description

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

opencode run reads non-TTY stdin to EOF before starting a prompt. That is the right default for intentional input such as:

cat context.txt | opencode run "review this"

The problem is that some supervisors give every child a pipe and keep its writer open, even when the command has no stdin payload. The prompt then never starts. This minimal Python control retains the pipe deliberately; changing PIPE to DEVNULL makes the same command progress to the expected invalid-model error:

import subprocess

args = ["opencode", "run", "--model", "invalid/provider-model", "reply with OK"]

def run(stdin):
    child = subprocess.Popen(args, stdin=stdin)
    try:
        return f"exit {child.wait(timeout=5)}"
    except subprocess.TimeoutExpired:
        child.terminate()
        child.wait()
        return "still waiting after 5s"

print("open pipe:", run(subprocess.PIPE))
print("closed input:", run(subprocess.DEVNULL))

Could run expose an explicit opt-out, for example --no-stdin? It would skip only the stdin read for that invocation; the existing default and pipe + positional prompt behavior would not change. I have a small implementation and subprocess tests ready if this interface is acceptable.

The symptom also appeared in #11891, which documented DEVNULL as a caller-side workaround. Related #25508 and merged #16300 show why silently ignoring piped input is not safe. When the caller controls descriptors, DEVNULL, stdin: "ignore", or closing the writer remains the workaround.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.