Fabric VS Code - remote kernel missing in git-cloned repos

[gcollinsAM]

Issue

Opening a repository via a standard git clone gives the full project workspace that modern teams require - multi-file navigation, tests, Git workflows, and AI assistants with whole-repo context. However:

• The Microsoft Fabric Runtime kernel does not appear in the kernel picker for notebooks opened from the cloned folder - only local kernels are offered.

• The only way to surface the Fabric kernel is to use the Fabric extension’s checkout flow, which opens a single notebook in isolation and discards the rest of the repo. This breaks normal Git ergonomics, hampers AI assistants that depend on repository-wide context, and forces a single-file workflow.

Net effect: developers must choose between running on the remote Fabric cluster or retaining a proper repo-centric workflow - they cannot have both at once.

Desired outcome

• When a user opens a locally cloned repository that is linked to Fabric, notebooks in that workspace should list the Microsoft Fabric Runtime in the kernel picker and execute on the remote Spark cluster.

• The extension should preserve the full folder workspace - no forced single-item windows - so Git operations, tests, and AI assistants maintain access to the entire codebase.

• In short, enable a normal local-first, Git- and AI-friendly workflow with remote Fabric execution, without requiring any special checkout flow.

[gcollinsAM]

And as a follow up, why does this extension exist along with the Fabric Data Engineering VS Code extension - they seem to serve very similar purposes?

[mksuni]

@gcollinsAM Thanks for your feedback. We’re teaming up with the Notebooks team to integrate Data engineering extension into Fabric extension. While we are not there yet to provide the desired experience you mention, but that’s definitely the direction we’re heading as we work closely with partner teams.