[Feature]: Project level terminal #6774

theodor349 · 2026-05-16T10:41:44Z

theodor349
May 16, 2026

Before submitting

I searched existing issues and did not find a duplicate.
I am describing a concrete problem or use case, not just a vague idea.

Area

apps/desktop

Problem or use case

I want to use e.g. pnpm run dev when I start working on the project, and I still want to be able to find it quickly when I am working in multiple chats. Currently I would have to open a dedicated terminal app or try to find the chat where I created the "persistent" terminal.

Proposed solution

Like the new chat button next to the project, there would be a new terminal button.
This button will open a new terminal tab, and the new terminal button switches to an open terminal for given project.

Why this matters

Those who do not want to open another terminal app, just to have a long running terminal session for a project.
The user can have short lived (chat based) terminal sessions and long lived project terminal sessions

Smallest useful scope

use the existing chat based terminal tab.
If the user is currently in a chat for the project, then open the tab and point it to the terminal session for the project.
If the user is currently in a chat in another project, open a new chat for the targeted project and open the terminal session for the project.

Add a small title or other indication to show the user that it is a project and nor chat based terminal session

Alternatives considered

Currently I need to find the chat terminal session, where I started the long running npm run dev command. Which is doable bu a hassle.
I can also open a terminal app and create the session in there instead.

Risks or tradeoffs

No response

Examples or references

No response

Contribution

I would be open to helping implement this.

Wiktor102 · 2026-10-25T09:38:12Z

Wiktor102
Oct 25, 2026

I'd love something like that!
However, the exact UX idea no longer fits because the sidebar has changed. Discussion #17456 describes some more robust functionality, and I think it supersedes this one.

0 replies

humbertogontijo · 2026-11-04T02:26:05Z

humbertogontijo
Nov 4, 2026

Middle ground: terminals keyed by project worktree, not by thread

The original ask here is a long-lived project terminal. #17456 goes further (a Processes page over every shell). If a single project-wide terminal is too coarse — or Processes is too large for a first step — a useful middle ground is:

Scope interactive terminals to (projectId, worktreePath) instead of threadId.

Why worktree, not whole project

A project often has several checkouts at once: main cwd plus agent worktrees. Sharing one terminal across all of those mixes shells that should stay isolated (cwd, env, running dev servers). Sharing across threads that use the same worktree matches how people actually work: two chats on the same branch/checkout should see the same drawer tabs; a handoff into a new worktree gets its own set.

Today the server keys sessions as threadId + terminalId (Manager.ts). Opening the drawer on another thread in the same worktree starts empty even if a pnpm run dev is already running next door.

Concrete behavior

Terminal create/list/subscribe resolve through a worktree scope derived from the current thread (worktreePath or project root when the thread has no worktree).
Opening the terminal drawer on thread B shows the same tabs as thread A when both resolve to the same worktree.
Chrome can still show which thread last focused a tab; ownership is the worktree, not the chat.
Threads on different worktrees (or different projects) never share tabs.
Settle / storage cleanup that removes a worktree still tears down that scope’s terminals (same lifetime as today’s worktree cleanup).

Relation to other Ideas

Idea	Fit
This discussion (#6774)	Same problem (find the long-running shell); worktree scope is a tighter key than “one terminal per project.”
#17456 Processes	Complementary: Processes can list/stop worktree-scoped shells later; it does not need to replace the drawer model.
#16825	Only panel size across threads — orthogonal.
#30557 / #29136	Agent-owned command PTYs — can sit in the same worktree scope once those exist.

Smallest useful PR (if direction is approved)

Re-key interactive terminal sessions from threadId → worktree scope for the existing drawer only. No Processes page, no project-global singleton, no agent-command migration in the first change.

Happy to implement after an explicit maintainer approval of this middle-ground scope (per CONTRIBUTING).

0 replies

Navigation Menu

Repository navigation

[Feature]: Project level terminal #6774

Uh oh!

{{title}}

Uh oh!

Replies: 2 comments

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

[Feature]: Project level terminal #6774

Uh oh!

theodor349 May 16, 2026

Before submitting

Area

Problem or use case

Proposed solution

Why this matters

Smallest useful scope

Alternatives considered

Risks or tradeoffs

Examples or references

Contribution

Replies: 2 comments

Uh oh!

Wiktor102 Oct 25, 2026

Uh oh!

humbertogontijo Nov 4, 2026

Middle ground: terminals keyed by project worktree, not by thread

Why worktree, not whole project

Concrete behavior

Relation to other Ideas

Smallest useful PR (if direction is approved)

theodor349
May 16, 2026

Wiktor102
Oct 25, 2026

humbertogontijo
Nov 4, 2026