[FEATURE]: Ephemeral one‑off sessions for opencode run (happy to implement)

[kamilchm]

I’d like to propose and help implement support for ephemeral one‑off sessions in opencode run—and I’m happy to do the implementation work if we can agree on the UX and design.

Right now, opencode run always creates a full session that is persisted to the local session store (e.g. under .local/share/opencode/). This is great for interactive work, but it’s less ideal when using opencode inside:

• Small utility scripts
• One‑shot CLIs
• CI/CD jobs

In these scenarios, each call is “fire‑and‑forget”: I only need the streamed output, not a persistent session that shows up in history.

---

What I’m proposing

Add an ephemeral mode for opencode run that:

• Allows a session to exist for the duration of the run (to route events, tools, etc.).
• Does not persist that session to storage, or deletes it immediately after the run completes.
• Keeps the behavior of tools, permissions, and output formatting the same as today.

A rough UX idea (open to alternatives):

• opencode run --ephemeral "…"
• or opencode run --no-session "…"

Some constraints that seem reasonable:

• Ephemeral mode is only valid for new sessions (no --continue / --session together with --ephemeral).
• If --attach is used, ephemeral mode may be disallowed (or clearly defined) since the remote server controls persistence.

---

Why this is useful

• Clean session history: Avoids filling the session list with throwaway script/CI runs.
• Better scripting ergonomics: Makes opencode run feel more like a simple CLI helper for automation, without having to manage session lifecycle explicitly.

---

Open design questions

I’d love maintainer input on a few points:

• Exact flag name and scope

  • --ephemeral vs --no-session vs something else?
  • Should this live only on run, or be a more general session option?

• Persistence semantics

  • Prefer “never write session at all” vs “write then auto‑delete once idle”?
  • Any analytics / usage tracking that depend on persisted sessions and need to be preserved?

• Compatibility rules

  • How should --ephemeral interact with:
    • --continue, --session
    • --attach
    • --share / auto‑share config

Once we settle on the UX and expected behavior, I’m happy to do the work.

[einarpersson]

This would be great, i've had the same thought! It would be very useful. Before when I used aichat I had a shell integration that allowed me to basically write natural language in the terminal and then hit a keybinding and have it being replaced by a suggested shell command. Very handy.

find all music in cwd
# magic
find . -type f \( -iname "*.mp3" -o -iname "*.flac" -o -iname "*.m4a" -o -iname "*.ogg" -o -iname "*.wav" -o -iname "*.aac" \)

source

[rekram1-node]

People have asked for this. I guess if you can find a sane way to do it that isn't too hacky I am all for it

[rekram1-node]

How should --ephemeral interact with:
--continue, --session
--attach
--share / auto‑share config

Emphemeral isn't compatible with the other ideas really so maybe make it exclusive or something...

[kamilchm]

I will try to figure it out somehow...

[ariane-emory]

Making it exclusive and having it only work in conjunction with run seems like a simple and reasonable approach to me.

[frouo]

@kamilchm still ready to implement it? 😃

It looks like we all are looking for a fire-and-forget session. Let's keep it simple, any of the following:

run + --continue, --session, --attach, --share + --no-session

would result in a CLI error telling us it’s not possible with --no-session

In the case of auto-share, sharing is ignored.

I personally prefer --no-session, the opposite of --session, easier spelling, not another option to remember.

PS: My use case is opencode run --command git-commit --no-session. A custom command has specific commit instructions that I launch outside the TUI after reviewing the diff. Once done, I really don't care about the session. For now, it pollutes my list of sessions... and since I'm a maniac I do /sessions - ctrl+d - ctrl+d all the time 😅

[indrajit-roy-sc]

I have some ideas around this:

1. opencode run "prompt" --ephemeral --continue OR opencode run "prompt" --ephemeral --session: opens the existing session in an ephemeral state (with the history) where the subsequent conversation isn't saved to the existing session.
2. Maybe attach could work the same way? Not sure about this. Haven't had the chance to use it yet. Need inputs.
3. --share I believe isn't there anymore.

@ariane-emory @rekram1-node thoughts?

My main motivation

The Problem: The "Context-Switching" Tax

Currently, getting quick feedback on a trivial question (e.g., "What does this RxJS operator do?") requires a heavy context switch: leaving the IDE, opening a browser, and starting a chat session. Even with Open Code, the "distance" to a simple answer feels too long for ephemeral, top-of-mind queries that don't belong in a project-bound chat.

The Proposal: Raycast Integration for Open Code

I want to build a Raycast Extension that leverages Open Code’s existing provider integrations to offer a "Quick Search" style interface for LLMs.

Workflow: Opt + Space -> Ask Open Code -> Type Question -> Get Answer -> Back to work.

Why this matters?
This bridges the gap between a full-scale coding agent and a quick lookup. It turns Open Code into a global utility for instant technical feedback, keeping developers in the "flow state" by minimizing the distance between a question and its answer.

And I don't want to pay 20$ for raycastAI

[ariane-emory]

@indrajit-roy-sc Using run in conjunction with --continue seems a little unusual to me, but I'm going to have to think it through. Leaving --ephemeral aside, does doing that work as things stand now? I'm not too sure as to whether it does or not.

[ayqazi]

Any thoughts/progress on this?

My idea to add to the pool:

opencode run-once <.....>

# or
opencode runonce <.....>

I'm not proposing the name but the idea of a separate command. Then there's not the added complication of making regular run flags interact with ephemeral mode

[jgmontoya]

This would be useful, is there any current workaround to avoid bloating the sessions history when using opencode run? For example I was thinking maybe trying to check the session id and then look it up and delete automatically but it seems like a very fragile approach