[Feature]: Linear issue panel in the right sidebar for the workspace's linked issue

[Cubatica]

Problem or use case

We run several repositories in Orca with Linear as the issue tracker, and most workspaces are created straight from a Linear issue (orca worktree create --linear-issue ABC-123, or "Use" from the Linear task list). So the workspace already knows which ticket it belongs to.

But once you are actually working in that workspace, the ticket is nowhere in the workbench. The right sidebar gives you Explorer, Source Control, Checks, Ports, AI Vault, Workspaces — everything about the code, nothing about the why. To re-read the acceptance criteria, check the current status, or leave a progress comment, you leave Orca for a browser tab, find the issue again, and come back.

That hurts most in the workflow Orca is built for: several agent workspaces in parallel. Each one is a different ticket, and the context for each lives in a different browser tab that you have to keep mentally paired with the right workspace. The ticket should travel with the worktree.

The linked issue is surfaced today in the left sidebar workspace card and in the status-bar workspace panel, but only as identifier + title + state. That is enough to identify the ticket, not enough to work from — no description, no comments, no way to act on it.

Proposed solution

Add a linear tab to the right sidebar that renders the current workspace's linked Linear issue.

Content: identifier + title, state, assignee, priority/estimate, labels, description, and the comment thread.
Actions (the ones Orca already supports elsewhere): change state, change assignee, add a comment, open in Linear.

Concretely, in src/renderer/src/components/right-sidebar/:

1. add 'linear' to RightSidebarTab in src/shared/types.ts, and to the literal list in normalizeRightSidebarRoute (src/renderer/src/store/right-sidebar-route.ts) so the tab survives a restart
2. add an ActivityBarItem entry in right-sidebar/index.tsx using the existing icons/LinearIcon
3. add the render branch in right-sidebar-panel-content.tsx
4. a new LinearPanel.tsx that reads activeWorktree.linkedLinearIssue / linkedLinearIssueWorkspaceId, fetches through the store's existing fetchLinearIssue + linearIssueComments, and composes the already-exported LinearIssueEditSection (layout="properties") and LinearIssueCommentFooter (variant="compact") from LinearItemDrawer.tsx
5. gate fetching on rightSidebarOpen && tab === 'linear', the way ChecksPanel does, since panels stay mounted when the sidebar closes

Almost none of this is new data work. Orca already fetches everything this panel needs: getIssue, getIssueComments, updateIssue, addIssueComment, getTeamStates/Labels/Members all exist in src/main/linear/, they are exposed over both the local IPC surface and the runtime RPC surface (so SSH/remote workspaces are already covered by runtime-linear-client.ts), and the renderer already caches issues in the Linear store slice. LinearIssueWorkspace.tsx is already a second consumer of LinearItemDrawer's exported sections, which suggests a third, narrower variant is the intended shape. This is a UI surface over data Orca already has, not a new integration.

Two design questions I would rather you rule on than guess:

Tab visibility. Should the tab be hidden when the workspace has no linked Linear issue (a new predicate alongside gitOnly / folderOnly / sshOnly in right-sidebar-activity-visibility.ts, which would mean threading the linked issue into the visibility state), or always visible with an empty state that offers to link one? Hiding keeps the activity bar clean; always-showing makes the feature discoverable and gives you somewhere to link from.

Provider scope. A linear tab is provider-specific, and CONTRIBUTING.md asks that generic behavior stay provider-neutral. Would you prefer a generic "Issue"/"Task" tab that renders the workspace's linkedWorkItem for whichever provider it belongs to (Linear now, GitHub/GitLab/Jira later), with Linear as the first implementation? That seems more in keeping with the codebase, and WorkspaceLinkedItem already carries the provider discriminator, but it is a bigger surface and I did not want to assume.

Alternatives or additional context

Why not a plugin. I looked at whether this could be a third-party plugin against contributes.panels / pluginApi 1 first, so as not to ask you for core changes. It cannot, today, for four independent reasons:

• workspace.readContext returns only branch, displayName, terminals[]. The projection in plugin-host-method-bindings.ts deliberately drops everything else, and nothing Linear-related exists anywhere under src/main/plugins or src/shared/plugins. A panel cannot learn which issue the workspace is linked to (short of regexing an identifier out of the branch name).
• The panel shell's CSP is connect-src 'none', so the panel frame cannot call the Linear API itself. That looks deliberate and correct, and I am not suggesting it change.
• A worker can reach the network, but the child→parent protocol has no panel-directed message and storage.* is panel: false, so a worker cannot get its results to a panel. The two halves of a plugin cannot exchange anything.
• There is no commands.invoke panel action (as [Feature]: Additional mount points for plugin panels (left nav, main view) #12531 also notes), and no capability kind that could grant network access.

Making this possible as a plugin would mean changing the same core files as just building the panel, plus designing a panel↔worker channel, and it would sit on a surface that is explicitly marked experimental and unfrozen. Building it into core looks like the cheaper and more honest option. Happy to be told otherwise.

Related issues: #3835 (sync worktree board status to Linear state) is the write direction of the same idea and would pair naturally with a panel. #12531 asks for more plugin panel mount points and overlaps on the plugin analysis above. Neither asks for a per-workspace issue panel.

Offer: I am happy to build this and open a PR, and I am starting on it now against the design above. I would still rather have your call on the two questions (hidden-vs-empty-state, and Linear-specific vs generic issue panel) so the PR matches the direction you want, and confirmation that you want the surface at all. If you would rather own it yourselves, no problem, treat this as a plain feature request.

[Cubatica]

Design feedback: the linked-issue panel is a great first step, but the surface we actually want is a project board

Two related pieces of feedback on the shape, from trying this against a real day-to-day workflow.

"Yes per project so you can easily see progress on the right hand side"

The panel as proposed here (and as shipped in #12698) shows one linked issue for the current worktree. That's useful for "what am I doing right now," but the question we actually want answered from the sidebar is "how is this project going" — and that needs the project's issues grouped by workflow state, not a single ticket. Concretely: open a workspace, see that project's board in the right sidebar — a compact set of columns (Todo / In Progress / Done, or whatever the team's states are), each showing its issues, so progress is visible at a glance without leaving the editor for the tracker's web UI. Scoped to the project, not the worktree, so you'd see the same board no matter which ticket in that project the current worktree happens to be linked to.

"Seems like it's missing backlog as well"

The reference view we were comparing against had Todo / In Progress / Done columns, a list/grid toggle, a View control, and a count indicator (e.g. "36 shown") — but no Backlog column. For a team that uses backlog as an intake funnel, a state-grouped view that omits it hides everything not yet started, i.e. most of the actual intake. Any board / state-grouped view should either always include backlog or make the state set configurable, rather than defaulting to hiding an entire stage of the workflow.

Framing: we don't think this replaces the single-issue panel proposed here, more that the two are complementary — issue detail for the specific ticket the worktree is on, board for the project the worktree belongs to. Both surfaces earn their place; a board doesn't make the linked-issue view redundant.

This also bears on the two open design questions already in this thread:

• Hidden vs. always-visible tab — a project board is a stronger case for always-visible than a single linked issue is: it's useful as soon as a workspace is attached to a project, even before/without a specific issue link.
• Linear-specific vs. provider-generic — a board grouped by workflow state isn't a Linear-specific concept (it's how most issue trackers represent a project), which reinforces going with a provider-generic abstraction rather than a Linear-only tab.

On plumbing, since cost matters here: the shipped panel/PR doesn't build a board today — it renders one linked issue via fetchLinearIssue / LinearIssueEditSection. Workflow-state data itself is already fetched elsewhere in the codebase (getTeamStates returns each state's id / name / type / color, and issue lists can already be filtered by stateIds via the existing attribute filter), so grouping issues by state client-side isn't new work. But listing issues scoped to a project is: the existing issue-list paths take a team id and a preset filter (assigned/created/open/completed/all), not a project id, so a project board would need a new "issues for project X" query — or a project filter added to an existing list path — rather than being a pure recombination of data the panel already fetches. Worth flagging up front since it changes the size of the ask relative to #12698.