Windows 11 Canary Build 27965 Adds Edit CLI Editor and Moves .NET 3.5 FoD

Microsoft’s latest Canary-channel preview for Windows 11 folds a long‑requested developer convenience into the OS while quietly changing how legacy runtimes are delivered: Build 27965 adds a small, open‑source command‑line editor called Edit (invoked simply by typing edit in Terminal) and removes .NET Framework 3.5 from the operating system’s preinstalled Feature‑on‑Demand inventory — a packaging change that has practical consequences for imaging, offline deployment, and enterprise compatibility.

Background / Overview​

Microsoft published the official Windows Insider announcement for Windows 11 Insider Preview Build 27965 on October 8, 2025, describing a redesigned, scrollable Start menu plus a set of platform‑level updates that pivot Windows’ developer and servicing posture in subtle but meaningful ways. The release is rolling to Insiders in the Canary Channel and is staged via server‑side gating, meaning visibility will vary across testers.
Two changes stand out for power users, developers, and IT teams:

• A first‑party, lightweight, modeless command‑line text editor — Edit — is now distributed with Windows and available to invoke from Terminal using edit. The editor is open‑source and installable via winget.
• .NET Framework 3.5 is no longer provided as a Windows Feature on Demand (FoD) optional component; Microsoft now points organizations to a standalone .NET Framework 3.5 installer for legacy scenarios while encouraging migration to modern .NET releases. This is a packaging and delivery change rather than an immediate end‑of‑support action, but it has operational weight.

This article explains what both moves mean in practical terms, verifies the key technical claims with public documentation and independent reporting, and offers concrete guidance and checklists for IT teams and power users preparing for the shift.

---

What is Edit? A native command‑line editor for modern Windows​

The promise: “a simple editor for simple needs”​

Edit is Microsoft’s small, terminal‑native text editor built to provide a low‑friction editing surface directly in command‑line workflows. Designed as a modeless Text User Interface (TUI) editor, Edit intentionally avoids the modal behavior of tools like vim and focuses on quick edits, accessibility, and approachable defaults. The product team describes it as compact (under ~250 KB) and targeted at users who need fast in‑terminal edits without switching to Notepad or a GUI editor.
Key design goals highlighted by Microsoft:

• Fast call‑and‑edit flow (type edit <file> or edit to start).
• Modeless operation to reduce the learning curve.
• Small binary footprint to keep the OS image lean.
• Terminal-friendly UI with keyboard shortcuts and mouse mode support.
• Open‑source development model to allow community contributions.

Core features (verified)​

Edit’s documentation and the developer blog list a practical feature set appropriate for quick command‑line work:

• Multi‑file support and a simple file switcher.
• Find & replace with regex support.
• Word wrap and basic undo history.
• Menu items mapped to keybindings (modeless usage).
• Mouse‑mode support for selection and scrolling in TUI environments.
• Winget installability via a published package ID.

Independent coverage and hands‑on reporting confirm the same feature highlights and the design intent: a compact, beginner‑friendly CLI editor that fills a longstanding gap on 64‑bit Windows systems where the old MS‑DOS EDIT.exe was not present.

How to get Edit and basic commands​

Microsoft’s public docs and the GitHub repository make the binary and source available. Practical install options:

• Install from Windows Package Manager:
• winget install Microsoft.Edit (package ID published by the project).
• Download releases or build from source at the project’s GitHub repository.

Once installed you can:

• Open a blank editor: edit
• Open or create a file: edit myfile.txt
• Use the in‑editor keybindings and the Ctrl‑P file switcher to navigate open buffers.

How Edit compares to alternatives​

• Vs. Notepad: Edit is faster for terminal workflows because it opens in the same shell context without switching windows or breaking command output history.
• Vs. Vim/Neovim: Those editors are more powerful and scriptable but modal, which carries a steeper learning curve for new users. Edit trades extensibility for predictability and a gentler onboarding experience.
• Vs. GUI editors (VS Code, Notepad++): GUI editors offer richer language features and extensions but at the cost of context switching and larger resource usage.

For quick config tweaks, one‑off script edits, and terminal‑centric daily tasks, Edit is functionally positioned as the default CLI editor that many Windows users lacked. Independent hands‑on reporting and Microsoft’s own blog both emphasize that role.

---

The .NET Framework 3.5 packaging change: what changed and why it matters​

What Microsoft announced​

In the Build 27965 release notes, Microsoft states: Starting with Build 27965, .NET Framework 3.5 is no longer a Windows Feature on Demand optional component. Organizations and users who still have business‑critical applications depending on .NET Framework 3.5 are directed to a standalone installer Microsoft provides for backward compatibility, though Microsoft also advises migration to modern .NET versions.
This is a reclassification of delivery rather than an immediate removal of functionality: existing apps continue to run, and the runtime itself remains supported under Microsoft’s product lifecycle rules. The operational difference is in how the component is acquired and provisioned during OS servicing, imaging, and offline deployments.

Practical operational implications (verified)​

• Image management and offline provisioning: Previously, a Feature‑on‑Demand component could be provisioned during image servicing with DISM or by referencing the FoD package in an image repository. With .NET 3.5 moved to a standalone installer, administrators must now include that installer in offline media or host it on an internal distribution point for air‑gapped environments. Failure to do so can break unattended installs that assume FoD availability.
• Patch and update pipelines: WSUS, SCCM, Intune, and custom deployment scripts that manipulated FoD packages must be reviewed and updated to accommodate the standalone installer workflow.
• Compatibility testing: Some legacy installers and ISVs still assume FoD behavior; plan compatibility tests for critical LOB apps and validate any required registry or side‑effectful behaviors after standalone installer deployment. Community reports going back months show intermittent installer issues in some environments, especially when Windows Update or matching ISO sources were expected; these troubleshooting patterns remain relevant.

What IT teams should do now — a checklist​

• Inventory dependencies:
• Use installer logs, application manifests, or dependency scanners to find apps that require .NET Framework 3.5.
• Acquire the standalone installer:
• Download and store the official standalone .NET Framework 3.5 installer in your internal repo and test it in your lab environment.
• Validate deployment paths:
• Test DISM offline servicing with your images, SCCM/WSUS distribution, and Intune deployment of the standalone installer.
• Prioritize modernization:
• For business‑critical apps, allocate time and resources to migrate to supported .NET versions (for security, performance, and maintainability).
• Document contingency plans:
• Keep rollback images and a recovery plan in case of post‑deployment issues.

These steps reflect the operational risk profile described in preview commentary and are consistent with Microsoft’s guidance to plan and test the standalone installer path.

---

The redesigned Start menu and Phone Link integration (brief)​

Build 27965 also introduces a single, scrollable Start surface that places All apps at top level and offers multiple browsing modes — Category, Grid, and List — plus a collapsible Phone Link panel inside Start for quick mobile interactions. The Start redesign is responsive to display size and includes explicit switches to hide recommended content. Microsoft’s Insider post describes the rollout as staged and gated. Independent coverage validates the same behavior and the responsive column counts reported in Microsoft’s notes.
The practical takeaway: the Start changes are primarily UX‑driven and beneficial for app discovery on larger displays, but enterprises should flag the current lack of deterministic category management as a support and training consideration for managed fleets.

---

Fixes, known issues, and the Canary trade‑offs​

Build 27965 bundles a set of fixes — taskbar autohide, corrections for a red video tint, and media playback fixes — alongside several notable known issues flagged by Microsoft, including File Explorer crashes with network transfers, Settings crashes on certain drive‑info pages, and some sleep/shutdown regressions on affected machines. Because this is a Canary build, these are expected: Canary is Microsoft’s early experimental channel and can contain instability not suitable for production systems.
Practical guidance: test on spare or lab hardware only; do not deploy Canary builds to user fleets. If you’re piloting, document hardware permutations that reproduce issues (network shares, certain video pipelines, or specific storage controllers) and file Feedback Hub reports to raise telemetry flags.

---

Security, privacy, and compliance considerations​

• Legacy runtime risk: Continued use of .NET Framework 3.5 beyond modernization timelines maintains a larger attack surface. Migrating to supported, patched .NET versions reduces long‑term exposure.
• Phone Link privacy surface: Surfacing phone content inside the Start menu increases the number of UI surfaces that can display sensitive data (SMS, photos, call status). Organizations with high compliance needs should review MDM policies and test Phone Link behavior before enabling the experience broadly.
• Server‑side gating: Features toggled by Microsoft can create inconsistent experience across fleets. This complicates auditing and user support, so enterprises should enforce pilot‑only policies and block Canary enrollments on production devices.

---

Risks, trade‑offs, and editorial analysis​

Strengths and why these changes matter​

• Developer ergonomics: Shipping a small, built‑in CLI editor reduces friction for terminal workflows and prevents the constant context switching between Terminal and Notepad or other GUI editors. It’s an obviously practical quality‑of‑life improvement for sysadmins, SREs, and developers.
• Streamlined servicing: Reclassifying .NET Framework 3.5 as a standalone installer reduces ongoing OS servicing complexity and signals Microsoft’s push toward modern .NET runtimes — a sensible direction for maintainability.
• UX gains: A scrollable, responsive Start and in‑Start Phone Link integration reflect a focus on discoverability and cross‑device workflows that align with how many users actually work on modern hardware.

Trade‑offs and potential downsides​

• Enterprise determinism: Auto‑grouped categories and server‑side gating create unpredictable Start layouts in managed environments; the lack of granular MDM/GPO controls for category management is a glaring omission for fleet predictability.
• Distribution friction for offline environments: Removing .NET 3.5 as an FoD item changes provisioning assumptions and requires updated imaging processes. This is operationally significant for air‑gapped and heavily regulated deployments.
• Canary instability: The presence of hard crashes and power regressions in this flight is not trivial. Early adoption without robust rollback plans puts production data and uptime at risk.

Unverifiable or community‑sourced claims — caution advised​

There are community reports of intermittent installer failures when enabling .NET Framework 3.5 in certain offline or mismatched ISO scenarios. While these reports are real and reflect troubleshooting patterns across forums, they are operational anecdotes rather than systematic Microsoft‑confirmed faults; administrators should treat them as red flags to validate in their own labs, not as universal showstoppers.

---

Recommended action plan (concise, executable)​

• Do not install Canary builds on production devices.
• Inventory and categorize .NET 3.5 dependencies immediately.
• Download and stash the official standalone .NET 3.5 installer in secured internal repositories and test it offline in your lab.
• Pilot the Start redesign on a small, representative hardware set to measure training and support impact.
• Evaluate Edit for developer workflows: ask dev teams to test winget deploys and confirm whether Edit reduces context switching in daily tasks.
• If managed fleet consistency is required, delay wide rollout until Microsoft provides deterministic controls or until a stable channel release is available.

---

Final takeaways​

Build 27965 is emblematic of how Windows 11’s evolution now blends incremental UX wins with packaging and tooling decisions that have real operational impact. Edit is a welcome, pragmatic addition that fills a practical gap for terminal users and should make quick edits less disruptive. The change to .NET Framework 3.5 distribution is less flashy but more consequential for IT teams: it’s a packaging shift that demands planning and inventory work.
For end users and hobbyists the new editor and Start refinements are immediate productivity wins. For IT administrators, the build is a reminder that modernization and operational hygiene matter: audit dependencies, test installers in offline scenarios, and keep Canary bits off production endpoints until features stabilize and management controls catch up.
The Windows Insider announcement and the public GitHub repo for Edit are the authoritative, current references for these changes; administrators and power users should use those resources as the starting point for testing and deployment planning.

---

---

Source: Windows Report Microsoft Adds 'Edit' Command-line tool to Windows 11; Drops Old .NET 3.5