Status: Public Preview — behaviour may change.

What it does

Lets you edit a Power BI Project (PBIP) — report and semantic model definitions saved as plain-text files — in Visual Studio Code or any code editor, then reload those changes back into Power BI Desktop. Desktop provides a built-in button to open the project folder in VS Code, and detects external edits with an Apply external changes banner so you don't have to reopen the project.

Key facts

• Requires the August 2026 release or later of Power BI Desktop on Windows.
• Needs the Power BI Project (.pbip) save option preview feature enabled (Options and settings > Options > Preview features), then a restart.
• The built-in VS Code launcher opens the project folder as the active workspace; it launches whichever folder holds the opened file (.pbip or .pbir).
• Desktop doesn't write your in-app changes to the files until you select Save — so save in Desktop before editing externally.
• When files change on disk, Desktop shows an Apply external changes banner; selecting it reloads the updated files.
• If Desktop has unsaved changes, applying external changes warns you they'll be overwritten. Cancel preserves both the unsaved Desktop changes and the unapplied external edits.
• Keep the PBIP root folder path short — each file must stay under the Windows 260-character path limit.

When to use / skip

Use it when you want source-style control over report and model definitions — bulk find-and-replace across visuals, scripted edits, diffing in Git — without the round-trip of closing and reopening the project. Skip it for quick one-off tweaks that are faster in the Desktop UI, and skip it entirely if you're not on PBIP format.

Configuration decisions

• Whether to standardise the team on PBIP as the working format so external editing and Git integration are available at all.
• Where the PBIP root lives — a short path near the drive root avoids the 260-character limit biting on deeply nested report folders.
• Which editor/tooling the team uses; VS Code has the built-in launcher but any code editor works.
• The save discipline: who saves in Desktop first, who edits externally, and how you avoid both sides holding unsaved changes at once.

Gotchas

• The overwrite direction is easy to get wrong. Applying external changes replaces unsaved Desktop work; saving in Desktop overwrites unapplied external edits. Two people editing the same PBIP at once will lose work unless they coordinate.
• Preview feature — the .pbip save option must be turned on per machine, so a teammate on default settings won't see any of this.
• The 260-character path limit is a real trap on model definitions with long table/measure names buried in a deep folder tree.
• It's Windows-only and tied to a specific Desktop release; mixed-version teams will get inconsistent behaviour.

Consultant notes

• This is the piece that makes PBIP-plus-Git actually pleasant for report developers — pitch it alongside Git integration, not on its own. Once external editing lands, treating PBIP as source-controlled text stops being theoretical.
• The save/apply overwrite rules are where you'll get support calls. Give the team a simple rule up front: finish and save in Desktop, then edit externally, never both at once.
• Sort the folder-path convention before the first project — retrofitting a shorter root after someone hits the 260-character wall mid-project is a nuisance.
• Being preview and per-machine, don't assume everyone on the team has it. Confirm the release version and the enabled preview flag before you build a workflow that depends on it.

---

Preview feature — revisit once external PBIP editing reaches GA and the .pbip save option ships on by default.