Unable to use opencode cli in a non-interactive pipeline

[S0LERA]

Description

Summary

In opencode v1.1.60 (running inside an OpenShift/Kubernetes pod), I cannot achieve a fully non-interactive, general-purpose automation workflow where:

• opencode run "Do X" creates/edits/deletes files in the working repository using tools like write/edit without any human interaction for arbitrary repositories and tasks (CI-style automation driven from Python via subprocess)

Despite tools being available, the agent does not execute write and the session ends in cancel. The alternative “server + attach” approach also lacks a batch mechanism, and run --attach fails.

Expected behavior

Running a command like:

opencode run "Implement X, create/modify/delete files"

should:

• use tools (write/edit)
• apply real filesystem changes in the repo
• complete non-interactively (CI-friendly)
• work generally across repositories/tasks

Actual behavior (observed facts)

1) Sessions are created with a restrictive permission preset

Every opencode run execution creates the session with an initial permission set that includes:

• question: deny
• plan_enter: deny
• plan_exit: deny

Example from logs:

  service=session ... created permission=[
    {"permission":"question","pattern":"*","action":"deny"},
    {"permission":"plan_enter","pattern":"*","action":"deny"},
    {"permission":"plan_exit","pattern":"*","action":"deny"}
  ]

2) Tools exist but write is never executed

The tool registry shows tools such as write, edit, bash, etc. are available, but in practice the agent:

• starts the loop
• may execute something trivial (e.g. bash ls)
• ends with cancel
• does not execute write
• therefore no files are created/modified/deleted

Why configuration does not fix it

A) opencode.jsonc permissive permissions do not override the session preset

Even with permissive configuration such as:

"permission": { "*": "allow" }

(and/or explicitly allowing question/plan_enter/plan_exit), the session still starts with question/plan_* = deny. This suggests a run/session-bootstrap preset taking precedence over config.

B) Built-in agents start with deny/ask rules (non-interactive hostile)

opencode agent list shows built-in agents (build, general, explore, etc.) include early rules like:

• question: deny
• plan_enter: deny
• plan_exit: deny

and also ask rules (e.g. external_directory: ask, reading .env*: ask).

In non-interactive mode:

• deny blocks immediately
• ask requires human approval; without it, execution tends to abort/cancel

C) A custom agent (e.g. autoaccept) does not remove the preset

I created a custom agent allowing tools and permissions and ran:

opencode run --agent autoaccept ...

The agent is loaded (logs show > autoaccept · azure-codex), but sessions still start with question/plan_* deny and write is not executed.

Conclusion: the restrictive preset is not only agent-defined; it also exists at run/session bootstrap level and is not overrideable (at least in this environment/version).

Why serve + CLI does not solve it in 1.1.60

1) opencode run --attach fails

Trying to run against a headless server:
opencode serve --hostname 127.0.0.1 --port 4096
opencode run --attach http://127.0.0.1:4096/ --agent autoaccept -m <model> "Create a file app.py"

fails with:

No context found for instance

This happens even when executing inside the repo directory (e.g. pwd=/tmp/workdir/TEST). It looks like a CLI bug/limitation in run --attach for v1.1.60.

2) opencode attach is not batch/non-interactive

opencode attach --help only supports:

• --dir
• --session
• --password

It does not provide:

• --message / --prompt
• --agent
• --model
• “run once and exit” behavior

Therefore, even if opencode serve is running, there is no CLI way to “send a prompt and apply changes” non-interactively.

3) opencode session and opencode acp do not provide a CLI batch execution path

• opencode session only supports list
• opencode acp only starts an ACP server (no CLI client command to send tasks/apply changes)

Impact on Python/CI automation

If automation relies on:

subprocess.run(["opencode", "run", ...])

it cannot reliably apply repo changes because:

• the session preset blocks the internal flow needed to reach write/edit
• there is no alternative CLI batch mode for serve
• run --attach fails with No context found for instance

Environment

• opencode version: 1.1.60
• platform: OpenShift/Kubernetes pod
• working directory example: /tmp/workdir/TEST
• model: gpt-5.1-codex-mini
• goal: fully non-interactive, general automation for arbitrary repositories/tasks

Requested improvements / questions

1. Provide a supported non-interactive mode for opencode run that can still execute repo-changing tools (write/edit) without requiring question/plan_*, or make the session permission preset configurable.
2. Fix opencode run --attach (No context found for instance) or document required steps to initialize context.
3. Add a batch mode to opencode attach (e.g., --message/--prompt, --agent, --model, “send and exit”) to enable CI automation against opencode serve without implementing a custom HTTP client.

Plugins

No response

OpenCode version

1.1.60

Steps to reproduce

1. In an empty working directory:

opencode run --print-logs --log-level DEBUG -m litellm/azure-codex "Create a file app.py"

2. Result:

• app.py is not created
• logs show session created with question/plan_* deny
• no write execution, session ends in cancel

3. Server attempt:
   opencode serve --hostname 127.0.0.1 --port 4096
opencode run --attach http://127.0.0.1:4096/ --print-logs --log-level DEBUG --agent autoaccept -m litellm/azure-codex "Create a file app.py"

Result: fails with No context found for instance

4. Attach help confirms no batch mode:
   opencode attach --help

Screenshot and/or share link

No response

Operating System

debian

Terminal

bash

[github-actions]

This issue appears to be related to several existing issues dealing with permission configuration and non-interactive automation:

• How do I completely disable the question tool? #13827: Permission overrides in config don't work (question tool disable)
• Path-based read permissions not enforced; catch-all rules always take precedence #13646: Catch-all permission rules bypass path-specific restrictions
• Agent Permission not work as expected #9927: Agent permission patterns not enforced as documented
• [FEATURE]: Ephemeral one‑off sessions for opencode run (happy to implement) #4489: Feature request for ephemeral/batch mode sessions
• opencode run hangs when model attempts to use question tool #11899: Non-interactive execution blocked when model calls question tool

Your issue provides the most comprehensive reproduction case for the underlying permission system failures. Consider cross-linking these issues to coordinate fixes.