Hello Windows Insiders, today we are releasing Windows 11 Insider Preview Build 28020.1546 to the Canary Channel (the desktop watermark is showing the wrong build number and will be addressed in a near term build). (KB 5074176)

What’s new in Canary Build 28020.1546

Changes and Improvements gradually being rolled out with toggle on*

• This update includes a small set of general improvements and fixes that improve the overall experience for Insiders running this build on their PCs.
• We fixed an issue with apps when working with files on OneDrive or Dropbox.

Reminders for Windows Insiders in the Canary Channel

• These builds can be unstable and may be released with limited documentation. Join Windows Insider – Get early access to Windows 11 features & updates

• The builds we release to the Canary Channel represent the latest platform changes early in the development cycle and should not be seen as matched to any specific release of Windows. Features and experiences included in these builds may never get released as we try out different concepts and get feedback. Features may change over time, be removed, or replaced and never get released beyond Windows Insiders. Some of these features and experiences could show up in future Windows releases when they’re ready.

• Many features in the Canary Channel are rolled out using Control Feature Rollout technology, starting with a subset of Insiders and ramping up over time as we monitor feedback to see how they land before pushing them out to everyone in this channel.
• The desktop watermark shown at the lower right corner of the desktop is normal for Windows Insider pre-release builds.
• Some features may show up in the Dev and Beta Channels first before showing up in the Canary Channel.
• Some features in active development we preview with Windows Insiders may not be fully localized and localization will happen over time as features are finalized. As you see issues with localization in your language, please report those issues to us via Feedback Hub.
• To get off the Canary Channel, a clean install of Windows 11 will be required. As a reminder - Insiders can’t switch to a channel that is receiving builds with lower build numbers without doing a clean installation of Windows 11 due to technical setup requirements.

• Check out Flight Hub for a complete look at what build is in which Insider channel.

Thanks, Windows Insider Program Team *Functionality will vary by device and market; text actions will be available across markets in select character sets. See aka.ms/copilotpluspcs.

• We’re sharing a novel approach to enabling cross-device passkey authentication for devices with inaccessible displays (like XR devices).
• Our approach bypasses the use of QR codes and enables cross-device authentication without the need for an on-device display, while still complying with all trust and proximity requirements.
• This approach builds on work done by the FIDO Alliance and we hope it will open the door to bring secure, passwordless authentication to a whole new ecosystem of devices and platforms.

Passkeys are a significant leap forward in authentication, offering a phishing-resistant, cryptographically secure alternative to traditional passwords. Generally, the standard cross-device passkey flow, where someone registers or authenticates on a desktop device by approving the action on their nearby mobile device, is done in a familiar way with QR codes scanned by their phone camera.  But how can we facilitate this flow for XR devices with a head-mounted display or no screen at all, or for other devices with an inaccessible display like smart home hubs and industrial sensors? 

We’ve taken a  novel approach to adapting the WebAuthn passkey flow and FIDO’s CTAP hybrid protocol for this unique class of devices that either lack a screen entirely or whose screen is not easily accessible to another device’s camera. Our implementation has been developed and is now broadly available on Meta Quest devices powered by Meta Horizon OS. We hope that this approach can also ensure robust security built on the strength of existing passkey frameworks, without sacrificing usability, for users of a variety of other screenless IoT devices, consumer electronics, and industrial hardware.

The Challenge: No Screen, No QR Code

The standard cross-device flow relies on two primary mechanisms:

1. QR code scanning: The relying party displays a QR code on the desktop/inaccessible device, which the mobile authenticator scans to establish a secure link.
2. Bluetooth/NFC proximity: The devices use local communication protocols to discover each other and initiate the secure exchange.

For devices with no display, the QR code method is impossible. Proximity-based discovery is feasible, but initiating the user verification step and confirming the intent without any on-device visual feedback can introduce security and usability risks. People need clear assurance that they are approving the correct transaction on the correct device.

Our Solution: Using a Companion App for Secure Message Transport

Scanning a QR code sends the authenticator device a command to initiate a hybrid (cross-device) login flow with a nonce that identifies the unauthenticated device client. But if a user has a companion application – like the Meta Horizon app – that uses the same account as the device we can use that application to pass this same request to the authenticator OS and execute it using general link/intent execution.

We made the flow easy to navigate by using in-app notifications to show users when a login request has been initiated, take them directly into the application, and immediately execute the login request.

For simplicity, we opted to begin the hybrid flow as soon as the application is opened since the user would have had to take some action (clicking the notification or opening the app) to trigger this and there is an additional user verification step in hybrid implementations on iOS and Android.

Here’s how this plays out on a Meta Quest with the Meta Horizon mobile app:

1. The Hybrid Flow Message Is Generated

When a passkey login is initiated on the Meta Quest, the headset’s browser locally constructs the same payload that would have been embedded in a QR Code – including a fresh ECDH public key, a session-specific secret, and routing information used later in the handshake. Instead of rendering this information into an image (QR code), the browser encodes it into a FIDO URL (the standard mechanism defined for hybrid transport) that instructs the mobile device to begin the passkey authentication flow.

2. The Message Is Sent to the Companion App

After the FIDO URL is generated, the headset requires a secure and deterministic method for transferring it to the user’s phone. Because the device cannot present a QR code, the system leverages the Meta Horizon app’s authenticated push channel to deliver the FIDO URL directly to the mobile device. When the user selects the passkey option in the login dialog, the headset encodes the FIDO URL as structured data within a GraphQL-based push notification. 

The Meta Horizon app, signed in with the same account as the headset, receives this payload and validates the delivery context to ensure it is routed to the correct user. 

3. The Application Sends a Notification of the Login Request

After the FIDO URL is delivered to the mobile device, the platform’s push service surfaces it as a standard iOS or Android notification indicating that a login request is pending. When the user taps the notification, the operating system routes the deep link to the Meta Horizon app. The app then opens the FIDO URL using the system URL launcher and invokes the operating system passkey interface.

For users that have the notification turned off or disabled, launching the Meta Horizon app directly will also trigger a query to the backend for any pending passkey requests associated with the user’s account. If a valid request exists (requests expire after five minutes), the app automatically initiates the same passkey flow by opening the FIDO URL.

Once the FIDO URL is opened, the mobile device begins the hybrid transport sequence, including broadcasting the BLE advertisement, establishing the encrypted tunnel, and producing the passkey assertion. In this flow, the system notification and the app launch path both serve as user consent surfaces and entry points into the standard hybrid transport workflow.

4. The App Executes the Hybrid Command

Once the user approves the action on their mobile device, the secure channel is established as per WebAuthn standards. The main difference is the challenge exchange timing:

1. The inaccessible device generates the standard WebAuthn challenge and waits.
2. The mobile authenticator, initiates the secure BLE/NFC connection.
3. The challenge is transmitted over this secure channel.
4. Upon UV success, the mobile device uses the relevant key material to generate the AuthenticatorAssertionResponse or AuthenticatorAttestationResponse.
5. The response is sent back to the inaccessible device.

The inaccessible device then acts as the conduit, forwarding the response to the relying party server to complete the transaction, exactly as a standard display-equipped device would.

Impact and Future Direction

This novel implementation successfully bypasses the need for an on-device display in the cross-device flow and still complies with the proximity and other trust challenges that exist today for cross-device passkey login. We hope that our solution paves the way for secure, passwordless authentication across a wider range of different platforms and ecosystems, moving passkeys beyond just mobile and desktop environments and into the burgeoning world of wearable and IoT devices. 

We are proud to build on top of and collaborate the excellent work already done in this area by our peers in the FIDO Alliance and mobile operating systems committed to this work and building a robust and interoperable ecosystem for secure and easy login.

The post No Display? No Problem: Cross-Device Passkey Authentication for XR Devices appeared first on Engineering at Meta.

WordPress is helping the non-profit fight the scourge of "link rot."

Neo shows its work, but until now that context was only viewable by the user that initiated the conversation. When you wanted a teammate’s input on a decision Neo made, you had to describe it in Slack or screenshot fragments of the conversation. Today we’re introducing task sharing: share a read-only view of any Neo task with anyone in your organization, full context preserved.

To share a Neo task, click the share button to generate a read-only link, then send it to a teammate. They see the complete picture: the original prompt, Neo’s reasoning process, the actions it took, and the outcome. Instead of writing up what happened and losing detail in the retelling, you share the task itself.

We built this with security as a core constraint. The original task system enforced strict RBAC, ensuring users could only see and act on resources they had permission to access. Task sharing preserves these guarantees. Viewers can see the conversation with Neo, but they cannot trigger any actions, and links within the shared task to stacks or resources still enforce the viewer’s existing permissions.

The feature is available now. The next time you want a second opinion or need to show a colleague how you solved something, share the task. You’re no longer working alone.

Apple released Xcode 26.3 with native support for agentic coding, marking a significant evolution in how development work is performed inside Xcode.

With this release, Xcode can now coordinate multi step coding tasks end to end. From a single request, Xcode can drive the full workflow: modifying project configuration, adding entitlements, generating new files, integrating APIs, building the project, detecting errors, and iterating until the build succeeds. The result is a complete feature implementation produced directly inside the IDE.

This capability is powered by Xcode’s adoption of the Model Context Protocol (MCP). Through MCP, Xcode exposes its internal tools and context so agents can work directly with project structure, documentation, build systems, and diagnostics. Because MCP is an open standard, developers are free to use any compatible tooling rather than being locked into a single provider.

Xcode 26.3 also introduces built in, one click integration with Anthropic Claude Code and OpenAI Codex. These integrations run natively inside Xcode, update automatically, and are optimized for efficient tool usage during larger tasks.

After a busy January (catch up here), we’re shifting focus to reliability and refinement. This month is about tightening core workflows, improving agent stability, and building on the MCP foundations we’ve been laying.

Agent Mode & Coding Agents

Reliability is the priority this month. We’re raising the floor on agent-driven scenarios with:

• Better progress and status indicators during long-running operations
• Improved handling of failures and retries so agents can recover more gracefully
• Diagnostics and logging improvements to help you diagnose and resolve issues faster.
• UX improvements across chat management, history, and agent-mode interactions
• Adding support for Agent Skills
• Coding Agent & Unified Sessions

Planning Agent

First steps toward a dedicated agent for multi-step task planning and execution.

• Dedicated Planning Agent built in

Copilot SDK & Platform Integration (Experimental)

We’re also beginning early work to better integrate the Copilot CLI into Visual Studio Copilot.

• Ways to surface the Copilot SDK’s harness/ CLI more directly in the IDE

Model Context Protocol (MCP)

MCP keeps external tools and services connected to VS in a governed, scalable way. February focus:

• Client ID Metadata Documents (CIMD)
• Visual Studio enables governance for MCP servers

Models & Context Management

Under-the-hood work to keep Copilot fast as context grows:

• Better handling of large or complex context
• Simplifying how context is reduced and capped to avoid unexpected behavior

Copilot experience in Editor

Smoother Copilot integration with existing editor behavior:

• Copilot keyboard shortcut to accept suggestion.
• Avoid IntelliSense and Copilot conflicts 
• Easier Copilot support from editor quick info

We’re excited for you to try these improvements as they roll out. As always, feedback is incredibly important—please upvote or comment on the linked Developer Community items so we know what matters most to you.

Thanks for continuing to build with us.

The post Roadmap for AI in Visual Studio (February) appeared first on Visual Studio Blog.