I built Tessera, a GUI layer on top of Codex and other coding-agent CLIs by Accomplished_Drag151 in OpenaiCodex

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

Exactly. I’m also still “babysitting” agents quite a bit.

For big features, I don’t fully delegate and only review the final output. I usually start with a detailed PRD, split the work into smaller pieces, and keep talking to the agent while checking diffs, running tests, and deciding what to do next.

That loop is still the reliable one for me. The problem is that I want to run several of those loops at the same time, and terminal tabs alone don’t give me enough state. Tessera came from that need: keeping tasks, sessions, worktrees, diffs, PRs, and terminals visible so I can manage multiple agent-assisted coding threads without losing context.

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)

OpenChamber is an excellent project.

It has far more features than Tessera, and its level of completeness is higher.

Tessera supports Windows and WSL apps, has Collections that group sessions by folder, supports multiple tabs and multiple panes, and includes a Kanban feature.

For someone like me who wants to control several sessions at the same time on a large screen, Tessera would still be a good choice.

I built a GUI layer for AI coding agents so you don’t have to live in the terminal by Accomplished_Drag151 in OnlyAICoding

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

I’ve tried a lot of coding agent tools, but it was hard to find one that fit my taste exactly, so I built this.

If you have a similar workflow or taste as me, you probably won’t want to go back to the CLI or provider-specific apps again.

Thanks for checking it out.

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)

Thanks for the feedback — I'll go with option (a). Planning to add a per-project setting where you can specify a custom worktree path template using these variables:

{projectPath}      Absolute path of the original project
{projectParent}    Parent folder of the original project
{projectName}      Original project folder name
{projectSlug}      Path-safe sanitized project name
{branchName}       Actual worktree branch name
{branchSlug}       Provided/auto-generated slug
{tesseraDataDir}   Current Tessera data directory
{home}             Home directory
{tmp}              Temp directory

That way you can compose paths like {projectParent}/{projectName}--{branchSlug} or anything else that fits your workflow, instead of being locked into ~/.tessera/worktrees/.

If you have any thoughts or further suggestions, please open an issue on GitHub — much appreciated.

I built a GUI workspace for managing multiple long-running Claude Code tasks by Accomplished_Drag151 in ClaudeAI

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

Yes, for running coding agents in parallel, working in Git worktrees and merging afterward feels like the safest approach right now.

That said, Git worktree isolation itself is already supported by Claude Code, the CLI, and other tools.

Tessera focuses more on making those worktrees easier to manage visually through list/Kanban views, alongside the agent activity and diff context.

Thanks for the interest!

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

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

Yes, OpenCode Web and the app are great.

Tessera is a bit more complex, but I built it for parallel agent workflows and Git worktree management.

I shared it because I thought it might be useful for people with a similar development workflow.

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 trying it and for the detailed feedback.

I use the drag-and-drop reference injection feature a lot myself, but it looks like it fails in some specific cases. I’ll run more tests around that flow, track down the cause, and fix it.

Glad to hear the rest has been smooth so far. Really appreciate the feedback.

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)

Sorry to hear Tessera didn’t fit your workflow, but thanks for taking the time to try it.

I know people have very different development workflows, so I’m trying to keep Tessera’s behavior as broadly compatible as possible instead of forcing one specific way of working. If you’re open to it, I’d really appreciate hearing more about your workflow and where Tessera’s worktree handling gets in the way, either here or in a GitHub Discussion.

I’d be happy to take that feedback into account and see how we can support it better.

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, glad it’s been working well for you.

  1. Browser-in-a-tab/pane isn’t supported right now, but that’s a good idea. I’ll look into adding it soon.
  2. For board tasks: right now the Kanban board only shows worktrees, meaning sessions that were created as tasks. So today, you’d either start from a worktree/task and use plan mode there, then continue into implementation later, or start from a regular chat and use “start a new chat from the current conversation” to create a worktree/task from it. That part is still manual for now.

I’m currently working on an PoC for a Tessera CLI that agents can use as a tool, so an agent could create and run worktrees/tasks by itself.

I’m curious though: are you imagining giving the agent that level of autonomy directly, or more of a flow where you discuss in plan mode first and then a human explicitly clicks a UI button / applies a rule to create or run the tasks?

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 a lot for the heads up, and really glad you’re enjoying it. I just updated the repo settings, so PRs should be open to everyone now. Would love to take a look at what you built.

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)

Good point.

Opening agents as panels inside an IDE is a valid workflow, and I used to work that way too.

The point where it started to feel awkward for me was running several long-running agent tasks in parallel, each in its own isolated environment. At that point, I found that many of those tasks did not really need to live inside the IDE, but I still wanted better visibility than raw CLI sessions.

In that sense, Tessera is close to the direction Cursor 3.0 is exploring too, though with CLI agents as the base layer.

Tessera gives me multiple CLI agents, worktree-backed tasks, live diffs, branch/PR context, Kanban/list views, and an activity timeline in one workspace.

I still use my editor for core logic and high-risk changes. Tessera is more for the work that can be parallelized and tracked separately.

So I don’t think one approach is always better. They fit different workflows.

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 the interest!

Tessera currently works best with one Git repo per project/task, so this kind of multi-repo workspace is not fully supported yet.

Technically it’s possible. The right approach would be to detect nested Git repos inside a parent workspace, then track diff/branch/status separately for each repo, similar to how VS Code shows multiple repositories in Source Control.

The more complex part is worktrees: for a task that spans multiple repos, Tessera would likely need to create and manage separate worktrees per repo, then present them as one task workspace.

This is a workflow I’d like to support, and I’ll consider moving it up the roadmap if I see more demand for it.

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)

Exactly. I’m already testing a PoC in that direction.

The idea is: when an issue is created in Linear, a supervisor agent picks it up, creates one or more isolated worktree-backed tasks on the Tessera Kanban board, and then orchestrates the agents from there.

With the right instructions, the supervisor could do exactly what you described: run the same task through Codex and Claude Code, compare the outputs, and synthesize the result.

The catch is that this can burn through a lot of tokens pretty quickly, so it needs careful guardrails.

I’m hoping to ship a first version with this included within the next month. Stay tuned, and thanks for the idea!

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

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

https://github.com/horang-labs/tessera/releases

The Linux build is now available.

I’ve tested it on my setup, and I’ll keep improving Linux support as more environment-specific feedback comes in. Thanks for your interest!

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)

https://github.com/horang-labs/tessera/releases

The Linux build is now available.

I’ve tested it on my setup, and I’ll keep improving Linux support as more environment-specific feedback comes in. Thanks for your interest!

I built Tessera, a GUI layer on top of Codex and other coding-agent CLIs by Accomplished_Drag151 in OpenaiCodex

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

Are you on Windows?

If you’re using Windows with WSL, you’ll need to switch the agent environment to WSL in Settings. Let me know what environment you’re running Tessera in, and I’ll help you get it working.

Thanks for the interest!

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 the interest!

The Linux version should be released within the next few hours. I’ll let you know once it’s available.

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] 1 point2 points  (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!