[Feature]: Show OpenCode agent state in workspace sidebar

[P-de-Jong]

Problem or use case

Orca currently shows live agent state for agents like Claude and Codex in the workspace sidebar. It would be useful to have the same visibility for OpenCode sessions, so users can see when an OpenCode agent is working, done, or waiting for input without opening each workspace.

OpenCode appears to support this through its plugin API. Plugins can subscribe to session and message events such as session.status, session.idle, permission.asked, question.asked, message.updated, and message.part.updated, which should be enough to map OpenCode activity into Orca's existing agent states.

Expected Behavior

• OpenCode sessions appear in the workspace sidebar like Claude and Codex sessions.
• Sidebar status reflects at least:
  • working or running
  • done or idle
  • waiting for permission or user input
• Ideally, the sidebar can also show the latest prompt or assistant message preview if available.

I'm definitely up for working on this if an approach is determined.

Proposed solution

Bundled
Bundle an Orca-managed OpenCode plugin that is injected into OpenCode sessions launched from Orca.
Example of this is Emdash. They write a plugin and inject a OPENCODE_CONFIG_DIR env variable in the terminal session.
Downside of this is when a user already has a OPENCODE_CONFIG_DIR set, this gets overwritten. You can write in the OPENCODE_CONFIG_DIR if its present, but that might be unwanted.

Seperate publish
Publish a separate optional OpenCode plugin that reports state back to Orca. Plugin should be added by the user in their OpenCode config. Warp does this for notifications

Alternatives or additional context

No response

[AmethystLiang]

Hey Pim, @brennanb2025 will take a look at this

[samlroberts]

I've been wondering about this a bit. With the most recent update, an opencode agent inside the workspace is showing when it's working, but the workspace overall doesn't seem to get that:

[P-de-Jong]

Huhh, I've never seen this when using OpenCode and it's my main driver 🤔

[samlroberts]

Huhh, I've never seen this when using OpenCode and it's my main driver 🤔

The worksapce indicator has never changed for me with opencode, but there was an update this morning to 1.3.41 that just added the agent specific one i believe

[P-de-Jong]

I have 1.3.41 installed and its not working for me :/

[AmethystLiang]

Hey @P-de-Jong and @samlroberts, I'm able to reproduce the opencode issue for the green circle now showing loading, though I'm not able to reproduce the inner agent status issue that @P-de-Jong is experiencing

will looking into the OpenCode loading indicator overall

P.S, the inner agent status is a new feature, and you can toggle them on/off here if needed

[P-de-Jong]

Strange. For me its working with Codex but not OpenCode. I'll see if i can find whats causing this then.
The "tiered-pricing" workspace has an OpenCode session running in a terminal.

[P-de-Jong]

Okay for some reason i completely missed Orca already has code injecting an OpenCode plugin and using OPENCODE_CONFIG_DIR.

Thing is, I already have that set on my system because we use it to point at a company wide opencode config repo. I had this exact same problem in Emdash.

Orca skips the plugin if the dir is already set.

We could not do that, but it would write a file in our config repo. And maybe show a warning and give the user a choice. Now it fails silently.
Or go the Warp way and make it a seperate plugin.

If the first solution is preferred i can add a PR for that.

[brennanb2025]

Taking a look at both of those issues! Thanks for raising them. Will have an update shortly!

[brennanb2025]

Hi @P-de-Jong, thanks for the offer and for flagging this issue - we're going to take a slightly different fix though.

The plan is to build a per-PTY overlay dir under Orca's userData, symlink your OPENCODE_CONFIG_DIR contents into it, drop the status plugin alongside, and point OpenCode at the overlay.
Outcome for you: company config keeps loading, status plugin works, nothing gets written into your config repo (no gitignore burden, no coworker-leak risk if it accidentally gets committed, no surprise on machines where you sync the repo but don't run Orca).

The reasons we'd rather not do the write-into-user-dir approach:

• It writes into a user-managed dir even with a warning toast (the toast is post-hoc consent)
• Cross-machine sync via dotfiles propagates the file to envs Orca doesn't run on
• The read-only-dir fallback (overwrite OPENCODE_CONFIG_DIR to a per-PTY dir) silently drops the user's entire OpenCode config - auth, model defaults, keybindings - for the sake of a status indicator. That's a worse failure mode than today's blank-status bug
• Cleanup needs filename coordination (Orca + Emdash, if you run both) plus a signature-versioned auto-rewrite for plugin updates

For what it's worth, this is the same pattern we already use for PI_CODING_AGENT_DIR in the same buildPtyHostEnv function — OPENCODE_CONFIG_DIR is structurally the same shape of env var (single path, user-controlled, Orca needs to inject alongside), so it lines up cleanly with the precedent.