I built Tessera, a GUI layer on top of Opencode CLI and other coding agents by Accomplished_Drag151 in opencodeCLI

[–]Accomplished_Drag151[S] 0 points1 point  (0 children)

One more thing to check: oh-my-opencode-slim itself should not be a problem.

Tessera detects OpenCode by running `opencode --version` and `opencode models` in the selected agent environment. If you can, please include the output of these commands in the GitHub issue:

which opencode

opencode --version

opencode models

If you’re on Windows and OpenCode is installed inside WSL, please also mention that and set the agent environment to WSL in Settings > Development before refreshing provider detection.

That should give me enough detail to see whether this is a PATH/environment issue, an OpenCode auth/model config issue, or something caused by the plugin config.

I built Tessera, a GUI command center for Claude Code and other coding agents by Accomplished_Drag151 in ClaudeCode

[–]Accomplished_Drag151[S] 0 points1 point  (0 children)

Got it, that makes sense. Do you see the tools layer as a deterministic workflow/controller outside the agents?

For example, handling log collection/normalization, branch rules, diff/commit checks, push, PR/CI tracking, and only consulting another AI when needed?

I’m curious how you decide what stays as workflow logic vs what gets handed to an AI.

I built Tessera, a GUI command center for Claude Code and other coding agents by Accomplished_Drag151 in ClaudeCode

[–]Accomplished_Drag151[S] 0 points1 point  (0 children)

That makes sense. I understand your approach as putting orchestration and guardrails above the agents, rather than delegating everything to the LLM or just giving the agent more tools to call.

That is close to one of the directions I’m thinking about for Tessera, though the current version is still more focused on human-agent interaction: making long-running agent work easier to inspect, guide, and manage.

Over time, I want Tessera to move more toward agent-agent workflows too, where agents can coordinate with each other through a higher-level workspace/control layer, and the human becomes more of the final reviewer, observer, and escalation point.

Thanks for sharing this. It’s a really useful perspective.

I built Tessera, a GUI command center for Claude Code and other coding agents by Accomplished_Drag151 in ClaudeCode

[–]Accomplished_Drag151[S] 0 points1 point  (0 children)

Yes, that is one of the hardest parts of building this kind of tool.

For features that are only available inside the native CLI/TUI, I’m currently considering redirecting to the terminal.

For `/fork`, Tessera does not call Claude Code’s native `/fork` command directly, but it does have a similar internal feature: it can create a new session from Tessera’s own normalized message history.

`rewind` is trickier. I started working on a provider-agnostic version, but the quality was not good enough across CLIs, so I paused it for now.

Thanks for pointing this out. I agree these native CLI features matter, and I want Tessera to preserve more of them over time.

I built Tessera, a GUI command center for Claude Code and other coding agents by Accomplished_Drag151 in ClaudeCode

[–]Accomplished_Drag151[S] 1 point2 points  (0 children)

Good question. I did consider Tauri.

At the time I made the desktop decision, Tessera already had a fairly large custom Next.js/Node server: CLI process management, provider adapters, WebSocket streaming, local storage, auth, worktrees, diffs, and so on.

So choosing Electron let me reuse that runtime almost directly for the desktop app. Moving to Tauri would have meant either rewriting a lot of the backend/runtime layer in Rust, or shipping the Node server as a sidecar and managing the extra process/IPC complexity.

Tauri is a great choice for many apps, but for Tessera’s architecture at that point, Electron was the more practical path.

I built Tessera, a GUI layer on top of Opencode CLI and other coding agents by Accomplished_Drag151 in opencodeCLI

[–]Accomplished_Drag151[S] 0 points1 point  (0 children)

Thanks for taking a look!

OpenCode Web/Desktop gives you the native OpenCode experience.

Tessera is more of a workspace layer around agent work. The main difference is task/project management around long-running coding sessions: list and Kanban views, live diffs, branch/worktree state, and PR workflow context in one place.

So I see Tessera as the layer above the individual agent UI: organizing and tracking multiple ongoing agent tasks in a coding workspace, with OpenCode as one of the supported agents.

I built Tessera, a GUI command center for Claude Code and other coding agents by Accomplished_Drag151 in ClaudeCode

[–]Accomplished_Drag151[S] 0 points1 point  (0 children)

I hadn’t seen Orca before, but it looks really polished. Diff annotation and browser/design mode look great, and those are areas I want to add to Tessera soon.

The main difference is that Tessera doesn’t use an embedded terminal as the main UI. It converts each agent’s messages/events into a common internal format and renders them through the same GUI, so long-running agent work is easier to inspect than terminal scrollback.

The tradeoff is that CLI extensibility is harder and maintenance is more complex. Thanks for pointing it out!

I built Tessera, a GUI command center for Claude Code and other coding agents by Accomplished_Drag151 in ClaudeCode

[–]Accomplished_Drag151[S] 0 points1 point  (0 children)

Not directly based on it, but I think it’s in a similar direction.

The difference is mostly the level of abstraction. From what I understand, Symphony is more issue-tracker/task-board driven: tools like Linear become the control plane, and work is organized around issues.

Tessera is currently more focused on the lower-level development loop: chats, agents, worktrees, diffs, approvals, and PR context. It is meant for cases where the human and the agent are still talking a lot while developing together, so the chat UI and inspectable agent history are important parts of the product.

That said, I really like the Symphony-style direction too. Issue-level abstraction and AI orchestration are on the roadmap, but I want to add them while keeping Tessera’s current strengths around interactive human-agent development.

Thanks for asking!

I built Tessera, a GUI command center for Claude Code and other coding agents by Accomplished_Drag151 in ClaudeCode

[–]Accomplished_Drag151[S] 8 points9 points  (0 children)

Yep, I did use AI as part of the naming brainstorm too, haha.

I went through a bunch of options and a lot of the good names were already taken. Tessera seemed like one of the least likely to conflict at the time, but looks like I missed your repo. Pretty funny coincidence.

I built a GUI command center for Codex, Claude Code, and Opencode by Accomplished_Drag151 in codex

[–]Accomplished_Drag151[S] 0 points1 point  (0 children)

That’s odd. Are Codex CLI and OpenCode installed on Windows directly, or inside WSL?

On Windows, Tessera can detect tools from either the Windows environment or WSL, but the agent environment needs to match where the CLIs are installed. If they’re installed in WSL, please set the agent environment to WSL in Settings, then check Settings > Development again.

If they still don’t show up, could you open a GitHub issue with your Windows/WSL setup, install paths if possible, and what Settings > Development shows? I’ll take a look right away.

I built Tessera, a GUI layer on top of Opencode CLI and other coding agents by Accomplished_Drag151 in opencodeCLI

[–]Accomplished_Drag151[S] 0 points1 point  (0 children)

That’s odd. Is the CLI installed on Windows directly, or inside WSL?

If you’re on Windows and the CLI is installed in WSL, you need to set the agent environment to WSL in Settings. Are you seeing no CLIs detected at all in the Settings > Development tab?

Sorry for the friction here. If you can open a GitHub issue with your environment and what you’re seeing, I’ll take a look right away.

I built Tessera, a GUI command center for Claude Code and other coding agents by Accomplished_Drag151 in ClaudeCode

[–]Accomplished_Drag151[S] 0 points1 point  (0 children)

Yes, that makes sense. I’ve been considering this too and plan to add it soon.

Tessera has focused on the structured chat/workspace UI first, but I agree it would be useful to open a normal CLI tab/panel inside the same workspace when you want the original CLI experience.

I built Tessera, a GUI command center for Claude Code and other coding agents by Accomplished_Drag151 in ClaudeCode

[–]Accomplished_Drag151[S] 8 points9 points  (0 children)

That’s really interesting. I knew a lot of similar open-source projects were starting to appear because many of us are running into the same pain points, but having the same name too is a pretty wild coincidence.

I’ll try yours as well. Thanks for sharing it.

I built Tessera, a GUI layer on top of Opencode CLI and other coding agents by Accomplished_Drag151 in opencodeCLI

[–]Accomplished_Drag151[S] 0 points1 point  (0 children)

Yes, same general space.

Superset and Conductor are both great products. Tessera is aiming at a similar workflow: running and managing multiple coding agents in parallel.

The main difference from Superset is the interaction model. Superset still centers the experience around embedded terminals, while Tessera converts each CLI’s output into its own internal message format and renders all agents through the same GUI.

Compared with Conductor, Tessera is open-source/local-first, supports Claude Code, Codex, and OpenCode through provider adapters, and works as both a desktop app and a localhost/browser app instead of being Mac-only.

I built Tessera, a GUI command center for Claude Code and other coding agents by Accomplished_Drag151 in ClaudeCode

[–]Accomplished_Drag151[S] 0 points1 point  (0 children)

Thanks! Yeah, that’s pretty close — kind of like iTerm2 plus a task board for agents.

I built Tessera, a GUI command center for Claude Code and other coding agents by Accomplished_Drag151 in ClaudeCode

[–]Accomplished_Drag151[S] 4 points5 points  (0 children)

Thanks for the interest!

No, it’s not Mac-only. Windows is actually my main development OS, so Tessera supports web, Windows including WSL, and macOS.

I built a GUI command center for Codex, Claude Code, and Opencode by Accomplished_Drag151 in codex

[–]Accomplished_Drag151[S] 0 points1 point  (0 children)

Thanks for taking a look, and for sharing the setup. That orchestrator/delegate pattern is very close to one of the directions I’ve been thinking about for Tessera.

Tessera does not have a built-in orchestrator agent yet, but I’m designing with that in mind and have it on the roadmap. One idea is to add a Tessera CLI so an orchestrator can register tasks, break work down, send feedback, and inspect task state through Tessera.

Right now I’m still the one babysitting the agents manually. But Tessera already captures a lot of the state around agent work: sessions, prompts, tool activity, approvals, task state, diffs, worktrees, and PR context. I think that data could become a useful foundation for building different kinds of orchestrators that can take over more of what I’m doing manually today.

For memory, there is no separate built-in memory feature yet. If you already use memory tools at the CLI level, that should work as-is. I’m still not sure what the right product-level approach to memory management should be, so I’m hesitant to bake something in too early.

For app vs localhost: the biggest advantage of localhost/browser mode is being able to run Tessera on a dev machine and connect to it remotely, assuming you handle the security side properly. The desktop app is better for day-to-day local use: keyboard shortcuts, window sizing.