[FEATURE] Projects (beta): Support first-class Local Claude Code sessions as project threads

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code Projects currently supports cloud threads and local execution through the "Work locally" / Remote Control path.

Remote Control local threads already run Claude Code on the user's machine and can work with the live local filesystem, local tools, MCP servers, hooks, settings, and permissions. The limitation I am trying to address is therefore not local filesystem or tool access.

The missing piece is the session model.

A normal Local Claude Code session that I start directly in Claude Desktop, the CLI, or an IDE is a first-class local session with its own normal lifecycle and interaction model. However, that kind of Local session cannot currently be a Project thread.

Conversely, when a Project runs work locally, the Project creates the thread through the Remote Control connected-folder path. That gives the Project access to local execution, but it is not the same user experience as having a normal first-class Local Claude Code session that also belongs to the Project.

This creates a separation between two very useful Claude Code workflows:

• Projects provides persistent coordination across multiple workstreams and threads.
• Local Claude Code provides the normal first-class development experience directly on the user's machine.

Another example of this gap is permission handling.

A normal Local Claude Code session can use the permission mode and permission rules configured for the user's workflow. A Project-created local thread, however, can behave differently and may pause for approvals that would not interrupt an equivalent standalone Local session.

For example, a delegated thread may stop and wait for approval when it needs to fetch documentation from a new web domain or perform another routine operation. Because the approval belongs to that specific thread, the delegated work can remain blocked until the user opens the thread and responds.

For long-running Project orchestration, this creates unnecessary friction: local execution is available, but the session does not fully behave like the Local Claude Code environment the user normally works in.

I would like these two concepts to be composable: a Project thread should be able to run as a normal first-class Local Claude Code session while still being owned, tracked, and coordinated by the Project.

Proposed Solution

Add Local as a first-class execution/session type for Project threads.

The ideal experience would be for a Project to be able to create or delegate a thread and choose a Local Claude Code environment in the same conceptual way that I can already start a normal Local session in Claude Code.

For example:

Project → New thread / Delegate task → Run on → Local

After selecting a machine and repository or working directory, Claude Code would create a normal Local Claude Code session that is also registered as a thread of the Project.

From the Project side, the coordinator should still be able to:

• assign work to the thread
• track its status
• receive results from it
• coordinate it with other Project threads
• provide the Project's instructions/context to the thread

From the Local Claude Code side, the thread should behave like a normal first-class Local session:

• run directly in the user's local Claude Code environment
• use the normal local working directory or worktree
• use the user's local filesystem, shell, processes, and tools
• use the user's normal Claude Code settings, hooks, skills/plugins, MCP servers, and permission rules
• support the normal Local Claude Code permission-mode lifecycle, including honoring the user's configured/default permission mode or allowing the mode to be selected for the thread, subject to the same account and organization policies as any other Local session
• be directly interactable through the normal Local Claude Code experience
• retain the normal Local session lifecycle rather than existing only as a Remote-Control-hosted Project worker

In particular, Projects should not need a separate permission model for a first-class Local thread.

If the equivalent standalone Local Claude Code session for that environment is configured to use Auto, Accept Edits, Bypass Permissions, or another supported mode, the Project thread should be able to use the same semantics rather than unexpectedly falling back to a more interactive approval flow.

This is especially important for delegated work. A thread that repeatedly pauses for routine permission prompts, such as fetching documentation from the web, loses much of the benefit of being managed asynchronously by the Project coordinator.

Remote Control could still be supported as an optional way to remotely interact with such a session, just as Remote Control can already be used with ordinary Claude Code sessions.

The important distinction is:

• Local should be a first-class Project thread execution/session type.
• Project should remain the orchestration layer that owns and coordinates the thread.
• Remote Control should remain an optional control/transport capability, rather than being the only path through which Projects can create local work.

Alternative Solutions

Continue expanding the existing "Work locally" / Remote Control path until it reaches full parity with normal Local Claude Code sessions.

However, I think explicitly treating Local as a first-class Project thread type would provide a clearer mental model and a cleaner long-term architecture.

The user should be able to think of:

• Cloud as one execution environment
• Local as another execution environment
• Remote Control as a way to remotely interact with a Local session

rather than treating "local execution" and "Remote Control" as the same concept.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

I primarily use Claude Code locally because my development environment includes repositories, local development servers, databases, MCP servers, CLI tools, and other machine-specific resources.

At the same time, Projects is useful for coordinating multiple long-running workstreams.

For example, suppose I ask a Project to:

Refactor authentication, update the documentation, and independently review the implementation.

The Project could decide to create:

• a Local Claude Code thread for the authentication refactor because it needs my local development environment
• a cloud thread for the documentation work
• another cloud thread for an independent code review

While the authentication thread is running, I may want to open that thread directly as a normal Local Claude Code session, inspect what it is doing, interact with it, run commands, or provide additional guidance.

The same should apply to permissions.

If that Local environment is configured for a particular Claude Code permission mode and permission rule set, the Project thread should preserve the same behavior.

For example, I should not have to repeatedly open a delegated thread just to approve routine WebFetch or other tool calls that my normal Local Claude Code configuration is already intended to allow.

After I stop actively interacting with the Local thread, the Project coordinator should still know that this is the same Project thread, continue tracking its state, and coordinate its result with the other threads.

This would make Projects a coordination layer over both cloud and first-class Local Claude Code sessions, rather than requiring locally executed Project work to exist only through the Remote Control worker path.

Additional Context

This request is not about adding local filesystem access to Projects. "Work locally" already provides that through Remote Control.

The distinction is between:

1. a Project-owned local worker spawned through the Remote Control path, and
2. a first-class Local Claude Code session that is also a Project thread.

Today, a Local session started directly by the user cannot be part of a Project, while Project local execution is tied to the Remote Control connected-folder workflow.

The desired model is:

• Local = a first-class Claude Code session/environment
• Project = an orchestration layer that can own and coordinate that session
• Remote Control = an optional way to remotely control that session

I am intentionally keeping this request scoped to Project-created first-class Local threads.

Attaching an arbitrary already-existing Local Claude Code session to a Project would be useful as a separate capability, but it is not required for this feature request.

Permission-mode parity

First-class Local session support should also include permission-mode parity.

Claude Code already has a Local permission model with configurable permission modes and permission rules. A Project-created Local thread should participate in that same model rather than having a separate Project-specific permission lifecycle.

This is not a request to weaken Claude Code's permission system, bypass managed organization policies, or automatically grant permissions that a normal Local session would not have.

It is simply a request for a Local Project thread to behave consistently with an equivalent Local Claude Code session on the same machine, repository, and configuration.

This matters particularly for asynchronous orchestration. If a delegated local thread unexpectedly stops for an approval that would normally be handled by the user's Local Claude Code permission configuration, the user must manually discover the blocked thread, open it, approve the action, and wait for work to resume.

That friction compounds when a Project is coordinating several threads in parallel.

Conceptual model

Current:

Project
├── Cloud thread
│ └── Claude Code in cloud environment
│
└── Work locally
└── Remote Control
└── Claude Code worker on local machine

Proposed:

Project
├── Cloud thread
│ └── Claude Code in cloud environment
│
└── Local thread
└── First-class Local Claude Code session
├── normal Local session lifecycle
├── normal Local permission configuration
├── directly interactable locally
└── Remote Control optionally available