[FEATURE]: Add non-interactive mode to "opencode run" #10411

Feature hasn't been suggested before.

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

Describe the enhancement you want to request

Description

Add a non-interactive mode (e.g. --non-interactive) to opencode run. In this mode, opencode will never await for user input. Some choices will need to be made about how to react to expected input, but whatever these are, in this mode the command will eventually finish without ever expecting user input.

Use case

I'm using opencode run --format json to run opencode from non-interactive scripts. In this case, for a benchmark. I have a permission policy that I want to be respected. Once the run finishes, my script would inspect all tool calls that were made (or attempted).

Behavior details

• It seems the main (or only?) thing that expects user input is permissions. So in non-interactive mode, a permission question should resolve to either reject or just abort the session. I think aborting and erroring out would probably make the most sense, and make this feature orthogonal to other proposed features for opencode run. In non-interactive mode, a permission question should just abort the session and exit the command. If someone wants the behavior to be answering allow/deny, that can be handled via explicit permissions.
• If the output is not a TTY, then this mode should be enabled by default. It's better to let the user deal with a clear error, than letting a process hanging up indefinitely.

Related issues

• Opencode Hangs when used as CLI tool #5888 is an example of someone hitting this issue in CI, getting their CI process to hang up. While the comments there proposing changing all permissions to either allow/deny are fair as a follow up solution, they do not address the fact that opencode run unexpectedly hangs up waiting for an input that will never come.
• subprocess.Popen hang issues on "opencode run message --json format"? #11891 another user who could have used an error message instead an indefinite freeze
• [FEATURE]: specify --tools on command-line for enabling/disabling tools #9386 possibly the best way in many case to fix a workflow that gets hanged up on permission issues
• [FEATURE]: Add --dangerously-skip-permissions (aka YOLO mode) #8463 also possibly useful when the preferred way to deal with permissions is allowing everything, but perhaps also achievable with --tools '*'.