Microsoft is getting ready to drop OneDrive support for iOS 18 and iPadOS 18. The change will affect the iPhone XR, iPhone XS and iPhone XS Max, because those phones can't be updated to iOS 26. The seventh-generation iPad will be left behind in the same way once Microsoft raises the app's minimum requirement to iPadOS 26. Nothing breaks today. The practical question is what happens to those devices once the cutoff arrives.

What has actually been announced​

MacRumors reports that OneDrive 18.12.1 is the final version to support iOS 18 and iPadOS 18, based on the release notes for Microsoft's latest TestFlight beta. Microsoft has also added a notice to its App Store listing saying support for iOS and iPadOS 18 will be dropped "soon." The notice recommends updating to iOS 26 or iOS 27 to keep receiving the latest versions.
There is no firm date. It's not clear when the change will reach the public version of OneDrive. French outlet iGeneration adds a detail on timing. It says the public App Store version at the moment is 18.11.2. So 18.12.1 appears to be a beta build, not yet a public release.

Which devices are affected​

The named devices are the three phones and one tablet that stopped at iOS 18 or iPadOS 18:

• iPhone XR
• iPhone XS
• iPhone XS Max
• iPad (7th generation)

Apple's iOS 26 compatibility page explains why. It lists iPhone 11 and newer, plus the iPhone SE (2nd generation and later). The XR and XS models aren't on it. Treat the four named devices as examples from the reporting. They are not a verified, complete list of everything that might be affected.

Will OneDrive stop working?​

Probably not right away. Existing versions aren't expected to stop working immediately. They just won't get new features, fixes or other app updates once Microsoft makes the change.
Be careful about reading that as a promise. The reporting doesn't say how long an old build will keep signing in and syncing. It also doesn't say whether Microsoft will later add service-side restrictions. One outlet, Android Pure, adds a reasoned caveat. Cloud storage apps talk constantly to a server that keeps changing. Once the app on your phone is frozen, any problem that appears stays unfixed on your device. That is analysis, not a Microsoft statement.

What Microsoft's documentation says today​

Microsoft's OneDrive system requirements page, last updated June 23, 2026, still lists the current minimum. It says an iPhone, iPad or iPod touch with iOS 18.0 or later. That page predates the reported change, so it doesn't contradict it. Watch it, and the App Store listing, for updates when the change goes public.
The same page includes a note on older systems. It says OneDrive only supports new installations on the stated minimum version. On a lower iOS version, you may only be able to update the app. That's a reminder that fresh installs on unsupported systems can fail even when an existing install keeps running.

A pattern, not a one-off​

Microsoft also retires older platforms on desktop. The same requirements page says that as of August 15, 2026, support ended for the OneDrive desktop apps on Windows 10 21H2 and earlier. The app may continue to function, but it won't get new updates, and compatibility and functionality aren't guaranteed. The wording matches the mobile situation: the app stays installed but is no longer supported.

What owners of affected devices should do​

1. Check your iOS version. Go to Settings > General > Software Update. Apple advises backing up before any update. If your device isn't on Apple's iOS 26 list, no update will appear.
2. Check your OneDrive version. If it's 18.12.1, you're on the last build for iOS 18, as Android Pure notes.
3. Make sure important files are safe. Android Pure suggests pulling critical files down to the device or a computer while sync still works normally. If you use OneDrive for camera uploads, confirm your photos have actually reached the cloud.
4. Keep the browser as a fallback. Android Pure says web access to OneDrive doesn't depend on the app being updated. I haven't confirmed that against a Microsoft statement, so test it yourself while you're still signed in.
5. Work or school accounts: ask your IT team. Microsoft's requirements page directs those users to their organization's helpdesk. Admins managing iPhones through Intune or similar tools should check their fleets for devices stuck on iOS 18.

Why is Microsoft doing this?​

Microsoft hasn't given a reason that I could verify. The security and performance rationale in some coverage is general industry reasoning. It isn't an attributed Microsoft statement. A MacRumors forum commenter speculated that the app might use newer Apple interface APIs. That is speculation too, and I wouldn't treat it as fact.
One real tension is worth noting. iGeneration points out that Apple still distributes security fixes for these older devices. The phones aren't abandoned by Apple. The app is moving on without them.

Bottom line​

This is a planning notice, not an emergency. The cutoff is announced but undated. Affected devices should keep working with their existing OneDrive build for now, though without updates. If you rely on an iPhone XR, XS, XS Max or a 7th-generation iPad, the sensible step is to secure your files and plan for hardware you can eventually replace.

Xbox has reportedly landed exclusive cloud-streaming rights to Grand Theft Auto VI at launch. If the report holds, Windows users could play the game on a PC without a console and without waiting for a native port. The deal is reported, not confirmed. Neither Microsoft nor Rockstar has announced it.

What was reported​

The Verge reported on Tuesday that Xbox has landed exclusive game streaming rights for Grand Theft Auto VI. Only Xbox Cloud Gaming could stream the game when it comes out on November 19. Kotaku, IGN, Insider Gaming and GTA BOOM all trace the story to Tom Warren's scoop. They are not independent confirmations or separate deals.
The trigger was an internal meeting. Warren wrote that Xbox CEO Asha Sharma told employees at an all-hands that Microsoft was preparing something no other platform holder is doing. Insider Gaming says the meeting also covered Xbox's "return to growth" and Project Helix. The streaming deal itself comes from Warren's sources, not from an official transcript.
GTA BOOM states the status plainly: no one at Microsoft, Rockstar or Take-Two has confirmed it yet.

What "exclusive" does and doesn't mean​

The exclusivity covers cloud streaming only. It does not make GTA VI an Xbox console exclusive, and it doesn't stop anyone buying the game on PS5. Rockstar's own platform lineup, per the research I was given, is PS5 and Xbox Series X|S on November 19, 2026. IGN adds that PlayStation holds the marketing rights, including limited-edition DualSense controllers, and that Rockstar has pushed a "play best" on PS5 message.
Key unknowns:

• Duration. Neither Kotaku nor the Verge-derived coverage says how long the exclusivity will last. Other services may get the game later, but no one has said when.
• Terms and regions. Pricing, eligibility and market availability for this specific title are not disclosed.
• Game-specific streaming details. There is no information on resolution, frame rate, latency, input support or save handling.

The PC angle, spelled out​

This is not a PC release. Rockstar Games has not announced a PC version of Grand Theft Auto VI. Cloud streaming runs the console build on remote hardware. Your PC only receives video and audio and sends your input back.
IGN puts the trade-off this way: a streamed version won't have the performance options, modding or other features of a native PC version. It calls streaming a serviceable workaround for people who don't want to wait for a port.
Xbox's own getting-started guide lists the PC requirements for the service in general:

• Windows 10 version 20H2 or later.
• A cloud-supported Game Pass plan.
• A stable connection, with Microsoft recommending at least 20 Mbps.
• Wired Ethernet where possible, or 5 GHz Wi-Fi.
• A controller for most games. Many titles also support mouse and keyboard.

Those are general service requirements, not a promise about GTA VI. Whether this particular game will support keyboard and mouse is unknown.

The November cloud changes matter here​

Microsoft announced its cloud changes on September 3, and they take effect in the same month as GTA VI. Beginning in November, Game Pass plans will include monthly cloud hours:
Microsoft said it expects the limits to affect 4% of Game Pass subscribers. Once the included hours run out, subscribers can buy more through the Xbox Store. Microsoft also plans a route without Game Pass. Players can buy cloud playtime hours and stream eligible games they own on supported devices. Microsoft said it would share pricing and further details before the changes take effect.
For a game this big, hours matter. A long open-world game could burn through a 5-hour Essential allowance in an evening or two. I can't say how many hours players will need. No one has published GTA VI hour estimates, and I won't guess.
Several outlets link the hour caps to GTA VI, and Kotaku suggests Xbox may have foreseen rising costs once players start streaming it. Microsoft's own explanation is only that the cost of cloud gaming grows as more people use it and play for longer. It does not mention GTA VI. Treat the timing as context, not as established cause.

Is "buy the game, then stream it" guaranteed?​

No. Microsoft says the new pay-as-you-go option covers eligible games players already own. Xbox's guide also describes a "stream your own games" feature for titles outside Game Pass. A reader could infer that buying GTA VI plus cloud hours would work. But the reporting does not say whether GTA VI qualifies, which storefront purchase it needs, or whether it will be in Game Pass. Don't buy a copy expecting a stream path until Microsoft publishes the eligibility details.

Analysis: why this is smart, and what to question​

• A hedge on console sales. IGN notes the story follows reporting that Xbox was worried about its GTA VI pre-orders. Xbox's chief strategy officer, Matthew Ball, denied that and said the game was breaking records on the platform. A streaming exclusive gives Xbox a stake in the launch that doesn't depend on console sales.
• It turns a PC gap into an opening. Rockstar's PC versions have historically arrived well after the console launches. GTA BOOM says it will likely be next year at the earliest, but that is the outlet's expectation, not an announced date. Until then, Xbox could be the only launch-day option for people without a PS5 or Series X|S.
• Skeptic's view. Streaming quality depends on your connection. Hour caps could make a 100-plus-hour game expensive. Single-source scoops can also shift as deals get finalized. Wait for an official announcement before planning purchases.

What PC users should do now​

1. Treat the deal as unconfirmed until Xbox or Rockstar announces it.
2. Check that your PC meets the general Xbox Cloud Gaming requirements. Test your network with a few streaming sessions of an existing cloud title before November.
3. Watch for Microsoft's pricing details for extra hours and for the pay-as-you-go option.
4. If a native PC version matters to you, keep waiting. Nothing in the reporting suggests one is imminent.

Bottom line​

Xbox's reported GTA VI streaming exclusivity could give Windows PC owners a way in on day one without buying a console. The report also leaves out the duration, the pricing, the eligibility rules and the streaming quality. Everything beyond "exclusive at launch" is still undisclosed.

Windows 11 has a drive health panel for NVMe SSDs, and most people never open it. Settings can show an estimated remaining life figure, an available spare figure and a temperature reading. It can also raise a critical warning. This guide covers where to find the panel, what each number means (including a wording problem in Microsoft's own documentation), and what to do if a warning appears.

Where to find it​

The route is short but buried. MakeUseOf's walkthrough and Microsoft's support page agree on the Windows 11 path:

1. Open Settings.
2. Go to System > Storage.
3. Choose Advanced storage settings > Disks & volumes.
4. Select your NVMe drive, then select Properties.

One guide notes that Win+R followed by ms-settings:disksandvolumes skips the clicking. I haven't verified that shortcut myself.
Windows 10 is different. Microsoft's support page, which covers both Windows 11 and Windows 10, gives the older route as Settings > System > Storage > Manage disks and volumes. From there you select Properties for the disk.
Some stability notes:

• Labels and layout can differ slightly between Windows versions.
• If you don't see health details, it doesn't always mean the SSD is bad.

NVMe only​

This is the limit that matters most. Microsoft's support note says Windows monitors NVMe SSDs and not SATA SSDs or hard drives. One guide says a missing Drive health section on those drives reflects the drive type, not a bug. If you have a SATA SSD or an HDD, you need a third-party S.M.A.R.T. tool such as CrystalDiskInfo. Microsoft doesn't endorse any particular tool, and MakeUseOf only mentions CrystalDiskInfo as one it has used.
The panel also isn't guaranteed to look identical on every NVMe drive. What appears depends on what the drive's firmware reports.

The three readings​

Microsoft's support page lists three disk health attributes: estimated remaining life, available spare and temperature.

Estimated remaining life​

Microsoft's own definition is awkward. The support page describes the attribute as an "approximate percentage used" based on the manufacturer's prediction of drive life. It adds that the value is capped at 0%, but a value below 0% is possible. Consuming that estimate does not automatically mean the device has failed.
That wording is the reverse of the label, and the label says "remaining". The underlying NVMe field is called PercentageUsed. Microsoft's developer documentation describes it as a vendor-specific estimate of the percentage of life used. A value of 100 means the estimated endurance has been consumed, and the value is allowed to exceed 100.
Third-party guides read the Settings number as life remaining. One says Settings shows life remaining, while the drive's log shows the same estimate as percentage used. Another says a result such as 95% generally means about 5% of the manufacturer's endurance measure has been consumed.
My advice:

• Treat a high number in the Settings panel as the healthy end of the scale, which matches how the label reads and how the guides above describe it.
• Don't rely on that reading alone. If you cross-check with a S.M.A.R.T. tool, remember that it will probably show "Percentage Used", where 0% is a fresh drive.
• This reading comes from third-party guides and the label. It is not something Microsoft's page states plainly, so don't treat it as settled.

One point is consistent everywhere. The figure is a manufacturer-based endurance estimate, not a countdown to failure. A drive can keep working past 0% remaining, and a drive can fail early from a controller or electronics fault. MakeUseOf makes the same point.

Available spare​

Microsoft describes this as a normalized percentage from 0% to 100% of the remaining spare capacity. SSDs hold back flash capacity to replace worn-out blocks. The NVMe documentation says each drive also reports an available spare threshold. When the spare figure falls below that threshold, the drive can signal an event.
That makes the manufacturer's threshold the real boundary. One guide notes that the value is normalized by firmware, and that manufacturers can use different thresholds. Treat a rule of thumb like "stay above 10%" as a loose guide only. A steady decline matters more than any single number.

Temperature​

Microsoft says this is the temperature of the overall device in degrees Celsius. The NVMe documentation calls it a composite temperature covering the controller and the NVM subsystem. It also says warning and critical thresholds are reported by the controller itself.
MakeUseOf suggests 50°C to 70°C under load is reasonable. I couldn't confirm that range in Microsoft's documentation. Drive-specific thresholds vary, so check your model's specification sheet. Regular, unusually high readings are worth investigating. Typical causes are a missing heatsink, poor case airflow or a drive sitting under a hot GPU.

Critical warnings​

Microsoft documents three critical warnings:
If you see a warning, Microsoft's advice is blunt. It strongly recommends paying attention, backing up your data and contacting Microsoft support about any further concerns. Microsoft lists slowness, freezing, longer startup times and trouble installing Windows updates as possible symptoms.
A practical response looks like this:

1. Copy important files to another drive or to cloud storage.
2. Open the disk's Properties and note which warning is active.
3. Check the drive maker's diagnostic utility and warranty terms.
4. Plan a replacement. Don't wait to see how long it lasts.

A read-only drive is the easy case, because you can still copy data off it. A degraded-reliability warning is less predictable, so back up first.

What Settings doesn't show​

The panel shows a small slice of what the drive reports. Microsoft's NVMe health log structure also covers:

• host data read and written
• power cycles and power-on hours
• unsafe shutdowns
• media errors
• error log entries
• time spent at warning or critical temperature
• up to eight temperature sensors

Whether a given monitoring program displays all of these depends on the program and on the drive. Not every SSD implements every optional field.
One guide notes that PowerShell's Get-PhysicalDisk shows a HealthStatus of Healthy, Warning or Unhealthy, and Get-StorageReliabilityCounter can pull wear percentage on NVMe. That guide itself calls this surface-level data. I haven't tested those commands.

Bottom line​

The Windows 11 drive health panel is a useful, free, one-minute check for NVMe owners. It is not a diagnosis. Treat warnings as a cue to back up, and treat a healthy-looking panel as a good sign rather than a guarantee. If you rely on this page, remember that Microsoft's description of "Estimated remaining life" is worded as percentage used. Check the number against your drive maker's tool if the distinction matters to you.
SATA SSD and HDD owners should install a S.M.A.R.T. monitor, because Windows won't surface this data for them. Whatever drive you have, keep backups, because an SSD can fail with little warning.

A private window does not change your browser fingerprint. That is the main finding of a TweakTown guide published October 6, 2026. The guide ran EFF's Cover Your Tracks test on Chrome, Edge, Firefox and Brave on one Windows 11 laptop. Tracker blocking, session cleanup and fingerprint reduction turn out to be three different protections, and many people assume they are one.
This is one writer's test on one machine. It shows how the protections differ, but it does not rank the browsers for everyone.

What the test measures​

EFF describes Cover Your Tracks as two things at once. Its stated goal is to help users find their own balance between privacy and convenience. It also acts as a research project on trackers and privacy add-ons.
Two separate questions are involved:

• Tracker handling. The test simulates loading different kinds of trackers and sets your protection level by whether they load. If a simulated tracker loads but its cookies are blocked, EFF reports "partial protection." That is because tracking by IP address and other means is still possible.
• Fingerprint uniqueness. EFF compares your browser's reported traits against other recent visitors. The traits include the user agent, screen resolution, time zone, fonts, and hashes of canvas and WebGL images. It also checks the Do Not Track header, platform, language and touchscreen support.

A good tracker score therefore says little about how identifiable your browser is. One of EFF's own pages says that an add-on intended to protect you can even lead to your full identification.

Test conditions​

The author, Yasir Mahmood, used maximized windows at 100% zoom on one Windows 11 laptop. The versions were:

• Chrome 154.0.8037.98
• Edge 154.0.4258.53
• Firefox 157.0
• Brave 1.96.60

He also noted that the headline verdict drifts between runs. Every new setup read "unique" the first time and "nearly unique" on reruns, because EFF's comparison data now included his own earlier visits. He therefore compared the underlying values, such as the canvas hash, rather than the headline label.

Chrome and Edge: private mode changed nothing​

Chrome's normal window came back "unique." It leaked at least 18.43 bits of identifying information among roughly 353,000 browsers EFF had tested in 45 days. Incognito read "nearly unique" at 16.85 bits. The author says the canvas hash, graphics string, font list, 12 threads and 16GB memory figure were identical in both windows.
The only change was in the tracker rows, which moved from "No" to "Partial protection." Incognito blocks third-party cookies by default, and that has nothing to do with the fingerprint. EFF's learn page says plainly that Chrome does not provide protection against trackers or fingerprinters in Incognito Mode.
Edge behaved the same way, with one Edge 154 detail. The author says Edge 154 no longer has a separate Strict option for InPrivate. InPrivate windows now follow the main setting under Settings > Privacy, search, and services > Tracking prevention. Moving that setting from Balanced to Strict turned both tracker checks to "Yes." All three Edge runs still produced the same canvas hash.
Two caveats apply to Edge:

• The Edge hash differed from Chrome's only because the author had graphics acceleration turned off, so Edge reported Windows' software renderer instead of his GPU.
• Microsoft's Edge 154 stable-channel release notes list the build 154.0.4258.53 from October 1, 2026. In the portion I could review, they do not mention the InPrivate Strict change. That detail rests on the author's observation.

Firefox: the one browser where private mode mattered​

Firefox was the only browser where the private window changed what was sent. Even a normal window on default Standard protection labeled the canvas and WebGL hashes "randomized by first party domain." It also described the GPU generically as "Radeon R9 200 Series, or similar." The author ties this to stronger Standard protection that Mozilla added in Firefox 151.
The private window went further:

• It reported eight threads instead of 12.
• It trimmed the font list, which cut the fonts' contribution from 6.05 to 3.83 bits.
• The verdict still read "unique," because EFF had never seen that combination before.

The author found that choosing Strict under Settings > Privacy and security > Enhanced Tracking Protection matched the private window value for value. That gives you comparable protection in a normal window.

The advanced option​

The guide also covers an optional experiment:

1. Type about:config in the address bar and accept the warning.
2. Search for privacy.resistFingerprinting.
3. Click the toggle to set it to true.

On the author's laptop, Firefox then reported a UTC time zone, four threads and a generic Mozilla renderer. The verdict was still "unique," because so few people run it that way, and sites showed times in UTC. The reset arrow beside the preference undoes the change. Mozilla recommends the regular protection for most people, since this setting breaks some sites.

Brave: randomization changed the verdict​

Brave was the only browser that changed the fingerprint row itself. Both its normal and private windows read "your browser has a randomized fingerprint." The canvas, WebGL and audio values showed as randomized per site. The renderer read simply "Brave," and the screen size was reported as 1680x1050. The other browsers reported 1536x864, which is the author's 1920x1080 display at 125% scaling.
Brave says these values change per site and per session, including after a restart. That makes visits harder to link, but it does not make you anonymous. The sharpest test was turning off Block fingerprinting at brave://settings/shields. Brave's canvas, WebGL and audio values then matched Chrome's exactly. On this laptop, the identifying signal comes mostly from the hardware, not from the browser's name.

A fair counterpoint​

A "randomized" label is not universally accepted as the best result. A Privacy Guides forum poster in 2025 noted that Brave still sent its time zone offset and GPU model details. The poster argued that this amounts to more identifying bits than other browsers, yet the test labels it "randomized." Another blog post argues that randomization without generalization can still leave stable signals. Those are community views, not controlled research. They do show that EFF's green label and a real-world privacy outcome are not the same thing.

Extensions: tracker rows up, fingerprint unchanged​

Adding Privacy Badger and uBlock Origin Lite to Chrome turned both tracker rows to "Yes" and earned a strong protection summary. Every fingerprint value stayed the same except one. Privacy Badger turned on Do Not Track, which only about one in four browsers in EFF's data sends. That added a distinguishing detail instead of hiding one.

What Windows users should take from this​

• Private windows do their real job. They clear that session's history, cookies and site data when closed. They are not a fingerprint defense in Chrome or Edge.
• Tracker blocking is not fingerprint protection. Check the raw values, not only the colored summary.
• Your everyday browser matters more than the window type. Brave randomizes by default, and Firefox Strict trims what it shares. Tor Browser and Mullvad Browser go much further. EFF's own guidance calls Tor Browser among the newer browsers built to thwart fingerprinting.
• Beware of odd combinations. A rare privacy setup can make you stand out, as the Firefox "unique" verdicts show.
• Keep your own tests fair. Hold the device, version, zoom, display scaling and graphics acceleration constant. Note your extensions. Rerun and compare values, not labels, because your earlier visits enter EFF's dataset.

Limits of the evidence​

The figures come from one laptop, specific builds and the author's own settings. They are not reproduced independently. The "unique" and "nearly unique" labels depend on EFF's changing dataset, and EFF notes that its test does not cover every tracking method. No browser here guarantees anonymity, and the TweakTown guide says so itself. The guide carries affiliate disclosures and shopping widgets, but its test results do not depend on them.
The practical conclusion is modest and useful. If you want to be harder to recognize, change your browser's fingerprint behavior, not just the window you open.

Microsoft has released security updates for CVE-2026-62698, Microsoft Digest Authentication Elevation of Privilege Vulnerability, an Important-rated flaw affecting a broad range of supported Windows client and server releases.
The issue is a numeric truncation error in Microsoft Digest Authentication. Microsoft states: “Microsoft Digest Authentication Elevation of Privilege Vulnerability: Numeric truncation error in Microsoft Digest Authentication allows an authorized attacker to elevate privileges locally.”
An attacker who successfully exploits the vulnerability could gain SYSTEM privileges, according to Microsoft’s advisory. That makes this a meaningful patching priority: SYSTEM is Windows’ highest local privilege level, the keys-to-the-kingdom account rather than merely another seat in the castle.

Vulnerability details​

• CVE: CVE-2026-62698
• Title: Microsoft Digest Authentication Elevation of Privilege Vulnerability
• Severity: Important
• CVSS base score: 7.8
• CVSS temporal score: 6.8
• CVSS vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C
• CWE: CWE-197
• Description: Numeric truncation error in Microsoft Digest Authentication allows an authorized attacker to elevate privileges locally.

Publicly disclosed: No
Exploited: No
Customer action required: Yes
Microsoft’s exploitation assessment is Exploitation More Likely.
The CVSS vector describes a locally exploitable issue with low attack complexity, where the attacker must already hold low-level privileges. No user interaction is required. A successful attack can affect confidentiality, integrity, and availability at a high level. In practical terms, this is not a remote unauthenticated break-in, but it can turn an existing foothold on a machine into complete local control.

Why this patch matters​

Elevation-of-privilege vulnerabilities are often most dangerous as part of a chain. An attacker may first obtain a limited account or limited code execution through another route, then use a local privilege escalation bug to reach SYSTEM. At that point, ordinary Windows permission boundaries provide very little resistance.
Microsoft’s advisory explicitly addresses the potential outcome:

“What privileges could be gained by an attacker who successfully exploited this vulnerability? An attacker who successfully exploited this vulnerability could gain SYSTEM privileges.”

Click to expand...

That risk applies to both workstation and server estates, including Server Core installations. Server administrators should not mistake a minimal GUI footprint for immunity; if an affected component is present and unpatched, the operating system version still requires the relevant update.

Affected Windows versions and fixed builds​

The following Microsoft updates remediate CVE-2026-62698. Administrators should deploy the applicable cumulative update for each operating system and architecture in their environment, then confirm the corresponding build number.

Windows 10​

• Windows 10 Version 1607 for 32-bit Systems (x86): For Windows 10 Version 1607 for 32-bit Systems (x86), install KB5120418 to reach fixed build 10.0.14393.9418.
• Windows 10 Version 1607 for x64-based Systems: For Windows 10 Version 1607 for x64-based Systems, install KB5120418 to reach fixed build 10.0.14393.9418.
• Windows 10 Version 1809 for 32-bit Systems (x86): For Windows 10 Version 1809 for 32-bit Systems (x86), install KB5120238 to reach fixed build 10.0.17763.9121.
• Windows 10 Version 1809 for x64-based Systems: For Windows 10 Version 1809 for x64-based Systems, install KB5120238 to reach fixed build 10.0.17763.9121.
• Windows 10 Version 21H2 for 32-bit Systems (x86): For Windows 10 Version 21H2 for 32-bit Systems (x86), install KB5120249 to reach fixed build 10.0.19044.7663.
• Windows 10 Version 21H2 for ARM64-based Systems: For Windows 10 Version 21H2 for ARM64-based Systems, install KB5120249 to reach fixed build 10.0.19044.7663.
• Windows 10 Version 21H2 for x64-based Systems: For Windows 10 Version 21H2 for x64-based Systems, install KB5120249 to reach fixed build 10.0.19044.7663.
• Windows 10 Version 22H2 for 32-bit Systems (x86): For Windows 10 Version 22H2 for 32-bit Systems (x86), install KB5120249 to reach fixed build 10.0.19045.7663.
• Windows 10 Version 22H2 for ARM64-based Systems: For Windows 10 Version 22H2 for ARM64-based Systems, install KB5120249 to reach fixed build 10.0.19045.7663.
• Windows 10 Version 22H2 for x64-based Systems: For Windows 10 Version 22H2 for x64-based Systems, install KB5120249 to reach fixed build 10.0.19045.7663.

Windows 11​

• Windows 11 Version 23H2 for ARM64-based Systems: For Windows 11 Version 23H2 for ARM64-based Systems, install KB5120240 to reach fixed build 10.0.22631.7517.
• Windows 11 Version 23H2 for x64-based Systems: For Windows 11 Version 23H2 for x64-based Systems, install KB5120240 to reach fixed build 10.0.22631.7517.
• Windows 11 Version 24H2 for ARM64-based Systems: For Windows 11 Version 24H2 for ARM64-based Systems, install KB5120994 to reach fixed build 10.0.26100.9106; install KB5121003 to reach fixed build 10.0.26100.9168.
• Windows 11 Version 24H2 for x64-based Systems: For Windows 11 Version 24H2 for x64-based Systems, install KB5120994 to reach fixed build 10.0.26100.9106; install KB5121003 to reach fixed build 10.0.26100.9168.
• Windows 11 Version 25H2 for ARM64-based Systems: For Windows 11 Version 25H2 for ARM64-based Systems, install KB5120994 to reach fixed build 10.0.26200.9106; install KB5121003 to reach fixed build 10.0.26200.9168.
• Windows 11 Version 25H2 for x64-based Systems: For Windows 11 Version 25H2 for x64-based Systems, install KB5120994 to reach fixed build 10.0.26200.9106; install KB5121003 to reach fixed build 10.0.26200.9168.
• Windows 11 Version 26H1 for ARM64-based Systems: For Windows 11 Version 26H1 for ARM64-based Systems, install KB5121000 to reach fixed build 10.0.28000.2704.
• Windows 11 version 26H1 for x64-based Systems: For Windows 11 version 26H1 for x64-based Systems, install KB5121000 to reach fixed build 10.0.28000.2704.

Windows Server​

• Windows Server 2012 (Server Core installation) (x64): For Windows Server 2012 (Server Core installation) (x64), install KB5120386 to reach fixed build 6.2.9200.26280.
• Windows Server 2012 (x64): For Windows Server 2012 (x64), install KB5120386 to reach fixed build 6.2.9200.26280.
• Windows Server 2012 R2 (Server Core installation) (x64): For Windows Server 2012 R2 (Server Core installation) (x64), install KB5120385 to reach fixed build 6.3.9600.23338.
• Windows Server 2012 R2 (x64): For Windows Server 2012 R2 (x64), install KB5120385 to reach fixed build 6.3.9600.23338.
• Windows Server 2016 (Server Core installation) (x64): For Windows Server 2016 (Server Core installation) (x64), install KB5120418 to reach fixed build 10.0.14393.9418.
• Windows Server 2016 (x64): For Windows Server 2016 (x64), install KB5120418 to reach fixed build 10.0.14393.9418.
• Windows Server 2019 (Server Core installation) (x64): For Windows Server 2019 (Server Core installation) (x64), install KB5120238 to reach fixed build 10.0.17763.9121.
• Windows Server 2019 (x64): For Windows Server 2019 (x64), install KB5120238 to reach fixed build 10.0.17763.9121.
• Windows Server 2022 (Server Core installation) (x64): For Windows Server 2022 (Server Core installation) (x64), install KB5120229 to reach fixed build 10.0.20348.5440; install KB5120242 to reach fixed build 10.0.20348.5499.
• Windows Server 2022 (x64): For Windows Server 2022 (x64), install KB5120229 to reach fixed build 10.0.20348.5440; install KB5120242 to reach fixed build 10.0.20348.5499.
• Windows Server 2025 (Server Core installation) (x64): For Windows Server 2025 (Server Core installation) (x64), install KB5120228 to reach fixed build 10.0.26100.33222; install KB5120233 to reach fixed build 10.0.26100.33296.
• Windows Server 2025 (x64): For Windows Server 2025 (x64), install KB5120228 to reach fixed build 10.0.26100.33222; install KB5120233 to reach fixed build 10.0.26100.33296.

Administrator checklist​

1. Inventory Windows versions and architectures. Separate x86, x64, and ARM64 endpoints; the target build is architecture- and release-specific.
2. Deploy the applicable cumulative update. Use the KB listed for the installed Windows release.
3. Restart where required. Cumulative Windows security updates commonly require a restart before the revised system components are active.
4. Validate the installed build. Check winver on client systems or use enterprise inventory tooling to compare the device’s build against the fixed build listed above.
5. Include server and Server Core systems. Windows Server 2012 through Windows Server 2025 are covered by this advisory, including the specified Server Core installations.
6. Prioritize systems where local access is realistic. Since the attack is local and requires authorization, systems shared by multiple users or exposed to post-compromise activity warrant particular attention.

The central lesson from CVE-2026-62698 is refreshingly unglamorous but important: a local account should not be able to become SYSTEM through a flaw in authentication handling. Apply the relevant Windows security update, verify the resulting build, and close off an escalation route before it becomes the second act in someone else’s intrusion story.

Valve has added a framerate distribution chart to the Steamworks partner dashboard. It shows developers how their games perform on Steam Deck, but only if the game is Steam Deck Verified.
Valve's Steamworks announcement is dated October 1 and says the partner dashboard now carries more information on how games perform on Steam Deck. The data is currently limited to Steam Deck Verified titles. Developers reach it from the partner landing page under Technical Tools > Steam Hardware Compatibility Review. The tool is aimed at developers, not at Deck owners. It matters to anyone who builds or buys PC games that run on Linux-based handheld hardware through the Proton compatibility layer.

What the new chart shows​

The earlier tools reported a single number. The April beta showed a trailing 30-day daily average, based on opted-in users who had logged playtime in the game. The new view is a distribution. It shows how much sampled gameplay falls into different FPS ranges. Valve says this gives a clearer picture than an average alone, especially when problems affect only part of a game or only some players.
Here is an example. A game averaging 45 FPS could be steady at 45. It could also be a mix of 60 FPS sessions and long stretches in the 20s. The average hides that difference, and the distribution shows it.
Valve says the chart should be read alongside the average framerate and customer feedback charts. It believes the three together give a clearer overall picture of what customers experience on Deck.

Where the data comes from​

Valve says the data comes from Steam Deck players who opted in to anonymized framerate data. It also says a majority of Deck players have opted in, across a wide range of games and play styles.
Valve gives no percentage, device count or session count. MIXED Reality News also reports that Valve does not say whether the opt-in is on by default. HotHardware says players opt in within SteamOS. Treat "a majority" as Valve's own unquantified claim. Developers also can't tell how well a given title's sample represents its audience.

Valve's four caveats​

Valve lists several reasons a low bar in the chart may not mean poor performance:

• Hardware ceilings. The Deck LCD tops out at 60 FPS and the OLED at 90 FPS.
• Player frame caps. Customers can change their frame limit. A game that holds 90 FPS on an OLED will still log lower-FPS sessions if some players cap it to save battery.
• Docked displays. Some players may be docked to an external display with a higher refresh rate than the Deck's own screen.
• Loading screens. MIXED reports that Valve also says the data includes all sampled time, including loading screens where framerate may drop sharply.

The practical reading is that a chart showing a big slice of time under 30 FPS is a prompt to investigate, not a verdict. Valve's own suggestion points the same way. If a significant amount of data lands in segments below 30 and players also report performance and stability problems, that could be a good signal to look into optimization or changing the default graphics configuration on Deck. The chart is most useful when low framerates coincide with complaints.

The Verified-only boundary​

The gate is where this story gets awkward. Valve's compatibility checklist makes performance part of Verified status. The default configuration must reach 30fps at 800p on Deck and 30fps at 1080p on Steam Machine. Valve's compatibility documentation adds that most failures in the checklist leave a game with the Playable badge.
The consequence is that some games are shut out of the chart. A title whose default settings miss the 30 FPS bar is more likely to lose Verified status. It then loses access to the tool that would show how far it falls short. Two points temper that reading:

• Verified is broader than framerate. The checklist also covers controller support and glyphs, text entry, launchers, device warnings, Proton support, resolution and text legibility. A Playable game may have failed on any of those. Playable does not automatically mean slow.
• The blind spot isn't proven to be total. Nothing in Valve's announcement says the games that most need optimization are all excluded. The gap is real, but its size is unknown.

Valve's own wording is "currently", so the restriction isn't described as permanent. It has also said before that it wants to broaden the data. In April it said it planned to add variance data and to bring the same view to Steam Deck Playable titles in a future update. That is Valve's earlier stated plan, not a commitment made in this announcement.

Why start with Steam Deck​

Valve defends the narrow scope in the announcement itself. As MIXED quotes it, Valve says it is starting with Steam Deck because every device has the same hardware configuration, which makes the data easier to understand. A fixed hardware target removes a large source of noise. A PC-wide version would have to untangle thousands of GPU, CPU and driver combinations.
HotHardware says the data could later extend to Steam Machine and Steam Frame. That is HotHardware's reading. MIXED reports that Valve promises no date and no equivalent for Steam Machine or general PC hardware. Treat expansion as possible, not scheduled.

What this means​

For developers of Verified games:

• Check the distribution, not just the average.
• Set the chart against player feedback before changing defaults.
• Allow for the 60/90 FPS ceilings and user-set caps.

For developers of Playable games:

• You still can't see this chart.
• Your own telemetry and QA remain the main option. Fixing the issues that cost Verified status could also unlock the data.

For players:

• Nothing changes on screen. MIXED reports the chart is developer-facing only, so players can't see what their own sessions contribute.
• Valve says compatibility ratings affect how a game is presented. They don't affect whether you can buy or launch it on a Deck.

The feedback loop is a good one: players share anonymous data and developers get a more honest view of performance. It is still a loop that only runs for games that already cleared the performance bar.

RPCS3, the open-source PlayStation 3 emulator that runs on Windows, macOS, Linux and FreeBSD, has hit a stability milestone. The project's official account announced on October 4 that all six PS3 Ratchet & Clank games can now be played on PC without crashes. The announcement lists Tools of Destruction (2007), Quest for Booty (2008), A Crack in Time (2009), All 4 One (2011), QForce (2012) and Into the Nexus (2013). It credits lead developer elad335 with improving "RSX FIFO GET accuracy."
"Crash-free" is not "playable," and the gap between the two matters for anyone planning a weekend of PS3 emulation on a Windows box.

What actually changed​

The fix is in RPCS3's emulation of the RSX, the PS3's graphics processor. FIFO means first-in, first-out. The RSX consumes a queue of graphics commands, and the "GET" pointer tracks how far the processor has read into that queue. If the emulator's GET value is wrong at the wrong moment, the command stream can desynchronize. That is general background, not a detail from the announcement.
RPCS3's history with this subsystem helps explain why such a fix is plausible. An older elad335 pull request on GitHub added a log prefix showing the current FIFO GET register. It also fixed FIFO stack recovery, and it targeted games that hit "RSX: FIFO error: possible desync event" errors. A separate 2022 change made RPCS3 suggest raising the RSX FIFO Accuracy setting after a crash. FIFO behavior has been a recurring source of stability problems in the project.
Two limits on the evidence:

• The announcement gives no commit, build number or benchmark data.
• One outlet, GameGPU, described a related stability update in broader terms and said a new build is on the project's site. That is secondary reporting, and I could not tie it to a specific build.

TweakTown says the emulator "can now read game instructions in the correct order." That is a simplification, not a technical explanation confirmed by RPCS3.

Crash-free is not the same as playable​

TweakTown notes that most of the six entries are still labeled "In-Game" on RPCS3's compatibility list. The project describes that tier as games that can't be finished, have serious glitches, or have insufficient performance.
Overclock3D adds a useful detail. The RPCS3 team says a game reaches "Playable" only when its performance matches PS3 levels on RPCS3's recommended specifications. Overclock3D reads this to mean that, with a sufficiently powerful PC, users can already get playable performance, while games stay at "Ingame" until the recommended hardware gets there. Notebookcheck likewise reports that the games aren't classed as "Playable" because of insufficient performance.
So the "In-Game" label here may reflect speed on reference hardware more than a pile of visible bugs. Nobody has published a per-game breakdown, so I won't guess which problem affects which title.

One more detail​

According to a post on X from the AGTP account, RPCS3 said the Ratchet & Clank HD collection never had this crash problem. That account also says only the games built on Insomniac's own PS3 engines did. This is a social-media relay of the team's replies, so treat it as lead-level information. It would explain why the list covers the later standalone releases.

How to check your own copy​

RPCS3's wiki explains that compatibility is tracked per Game ID, batched by media, and not per game title. The disc and digital versions of the same game have separate entries on the list. Regional IDs also need separate reports.

1. Find the Game ID of the edition you own: disc, PSN download, or regional release.
2. Search the RPCS3 compatibility list for that ID and read its status.
3. Open the linked forum thread for recent user reports on hardware and settings.
4. Update to a current RPCS3 build before testing. I couldn't verify which build first contained this fix.

If you still get crashes, RPCS3 has previously suggested raising the RSX FIFO Accuracy setting. I couldn't confirm that doing so is needed or helpful for these six titles after the new fix.

Hardware expectations​

Neither source gives a recommended CPU or GPU, game-specific settings or benchmarks for these games. TweakTown's advice that you'll need a "beefy" PC is broad and unquantified. Treat performance as unknown until you test your own setup. Older forum reports for Tools of Destruction exist, but they come from earlier builds and different hardware. They shouldn't be taken as current performance data.

The bigger picture​

The milestone fits a strong year for the project. According to Overclock3D, the "Playable" count has risen from 2,558 in January 2026 to 2,809, and RPCS3 rates more than 99% of PS3 games as "Ingame" or "Playable." RPCS3's wiki table shows the September 2026 figures: 2,809 Playable, 721 Ingame, 31 Intro and 2 Loadable, out of 3,563 entries.
The takeaway: a project-wide stability fix is real progress, and it gives these six games a better shot at a full "Playable" rating. Until the compatibility entry for your Game ID changes, expect to tune settings and possibly accept uneven frame rates.

Microsoft’s October security release addresses CVE-2026-73009, a Critical Windows Secure Socket Tunneling Protocol (SSTP) remote code execution flaw that administrators should treat as a priority patching item wherever affected Windows clients or servers are deployed.
The vulnerability’s exact title is Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution Vulnerability. Microsoft describes it as: “Use after free in Windows Secure Socket Tunneling Protocol (SSTP) allows an unauthorized attacker to execute code over a network.”

Why CVE-2026-73009 matters​

The issue is classified as CWE-416, a use-after-free weakness. This class of memory-safety flaw occurs when software continues to use memory after it has been released. In the worst case, carefully constructed network input can turn that programming mistake into code execution.
Microsoft’s advisory states that an unauthenticated attacker could send a specially crafted packet to an affected service over the network. If exploitation succeeds, the attacker could execute code on the target system. No authentication or user interaction is required.
The security rating reflects that potentially serious outcome:

• Severity: Critical
• CVSS base score: 9.8
• CVSS temporal score: 8.5
• CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C
• CWE: CWE-416
• Exploitation assessment: Exploitation Less Likely
• Publicly disclosed: No
• Exploited: No
• Customer action required: Yes

That CVSS vector is the attention-getter: network access, low attack complexity, no privileges, and no user interaction. In short, this is not a vulnerability that waits patiently for someone to click a suspicious attachment.

Patch the Windows systems in scope​

Microsoft has supplied updates across a notably broad range of Windows client and server releases. The practical goal is straightforward: deploy the applicable KB and verify that systems reach the corresponding fixed build.

Windows 10​

Windows 11​

Windows Server​

Administrator checklist​

1. Identify systems running one of the affected Windows products listed above.
2. Match each device’s Windows release and architecture to its required KB.
3. Deploy the update through the organization’s normal Windows update-management process.
4. Confirm successful installation and validate the fixed build number, rather than treating update approval as proof of remediation.
5. Give particular operational attention to systems that expose or rely on SSTP services, since Microsoft’s stated attack path involves a specially crafted network packet.

CVE-2026-73009 is an example of why monthly Windows security maintenance is not merely housekeeping. The remediation is clearly mapped to KB packages and target builds; the job now is making sure the fleet actually arrives there.

When an app vanishes from Open with, the usual culprit is not a missing Windows feature. It is a broken, incomplete, or overly narrow file-association registration. Windows may still show the program in Start, and the app may launch perfectly well on its own, yet it no longer advertises itself as an option for the file you clicked.
The good news: this is normally repairable without registry surgery, “association fixer” utilities, or the sort of command-line archaeology that turns a five-minute annoyance into a Saturday project.

First, identify the exact file type​

Before changing anything, confirm the file’s extension. A photo might be .jpg, .jpeg, .png, .heic, or a camera manufacturer’s raw format; a video might be .mp4, .mkv, or .mov. Two files that look similar in File Explorer can require entirely different apps.
If extensions are hidden:

1. Open File Explorer.
2. Select View.
3. Choose Show > File name extensions.
4. Note the extension after the final period in the file name.

This matters because Open With is built around the file type, not the broad category. An app may correctly appear for .mp4 but not for .mkv, for example. That is not necessarily a Windows fault; the app may simply not claim support for that particular format.

Use “Choose another app” before resetting anything​

Right-click one affected file, then select:
Open with > Choose another app
Windows should display recommended programs. If your preferred app is missing, select Choose an app on your PC and browse to the application’s executable file, usually in one of these locations:

• C:\Program Files
• C:\Program Files (x86)
• Your user profile’s AppData\Local\Programs folder for some per-user installs

Choose the app’s main .exe file—not an updater, launcher, uninstall utility, or helper process. If Windows offers the checkbox to always use that app for this file type, enable it only if that is genuinely what you want.

What success looks like​

After choosing the app, right-click another file with the same extension. The app should now appear in the Open with list, and the file icon may update after a short delay or a File Explorer restart.
Microsoft’s current Windows guidance confirms that Open with can be used both for a one-time launch and for assigning an app as the default handler for a file type. It is the safest first-line fix because it preserves the user’s control over the association.

Check the default association in Settings​

If the app can be selected manually but does not remain available—or Windows keeps opening files in the wrong program—check the association directly.

Windows 11​

1. Open Settings.
2. Select Apps > Default apps.
3. In the search box, enter the extension, including the period—for example, .pdf, .txt, or .png.
4. Select the matching file type.
5. Choose the app you want Windows to use.

You can also search for the application by name in Default apps. This shows the file and link types that Windows currently allows that app to handle.

Windows 10​

1. Open Settings.
2. Go to Apps > Default apps.
3. Select Choose default apps by file type.
4. Find the extension and assign the preferred program.

If the application is absent from both the Open With dialog and the Default apps page, do not assume Windows is merely hiding it. That typically points to the application’s own registration being damaged or incomplete.

Repair the missing application​

Windows cannot reliably offer an app that has not registered itself as capable of opening the file type. Reinstalling or repairing the affected app often restores those registrations.

For Microsoft Store apps and supported Windows apps​

1. Go to Settings > Apps > Installed apps.
2. Find the affected app.
3. Select the three-dot menu next to it.
4. Choose Advanced options.
5. Select Repair.

Try Open With again after the repair completes.
If Repair is unavailable or does not solve the problem, use Reset only with care. Reset can remove the app’s local data, saved settings, and sign-in state, depending on the app. Think of Repair as a tune-up; Reset is closer to emptying the glove compartment onto the driveway.

For traditional desktop programs​

Open Control Panel > Programs > Programs and Features, select the program, then choose Repair or Change if either option is available.
If no repair option exists, download the current installer from the software publisher and run it again. During setup, look for options such as:

• Repair
• Modify
• Register file associations
• Associate supported file types
• Install for all users

Select only the file types the app truly supports. A media player that claims every extension in sight may sound convenient until a spreadsheet double-click suddenly launches a concert video player. Computing has enough surprises already.
Microsoft’s developer documentation explains why this works: programs must register the file types they support before Windows can offer them as candidates in the Default apps and Open With experiences.

Rebuild the available-app list safely​

There is no supported “rebuild Open With cache” button, and that is by design. Modern Windows protects default associations so that malware and overly enthusiastic installers cannot silently seize control of your files.
Use this safe sequence instead:

1. Close the affected app.
2. Repair or reinstall it using its official installer or Windows’ Repair feature.
3. Restart Windows or at least sign out and back in.
4. Return to Settings > Apps > Default apps.
5. Assign the app to the specific extension.
6. Test with a second file of the same type.

This refreshes the app’s legitimate Windows registrations without editing protected association data manually.
Avoid registry “fixes” that promise to reset every Open With choice. Microsoft documents that default-app settings are protected and that registry-based attempts to force them are unsupported. Such tweaks can also wipe personal preferences, cause Windows to reset an association later, or create a mess that looks suspiciously like progress until the next update.

If the app still does not appear​

Work through these checks:

• Confirm the app supports the extension. An app may open one format but not another closely related format.
• Update the app. Older versions may not properly register themselves on newer Windows releases.
• Try another file of the same extension. A damaged or unusual file can produce misleading results.
• Check whether the file is actually a shortcut or renamed file. Changing .txt to .pdf changes the label, not the file format.
• Use “Choose an app on your PC.” The app may not be recommended but can still be selected manually.
• Ask your IT administrator on a work-managed PC. Group Policy or mobile-device-management rules can apply default associations at sign-in and override local choices.

For an unknown extension, Windows also offers the option to search the Microsoft Store. That can be useful, but do not install the first app with a cheerful icon and a suspiciously broad promise to open “all files.” Verify the publisher and the supported format first.

The practical takeaway​

Missing Open With entries are usually an app-registration problem, not a reason to rebuild Windows. Start with Choose another app, verify the extension, set the association in Default apps, then repair or reinstall the missing program if Windows still does not list it.
That approach is safer than registry edits, survives normal Windows updates more gracefully, and leaves your file associations under your control—exactly where they belong.

GitHub has declared stacked pull requests generally available. The feature began rolling out in public preview to all repositories on July 30, 2026. The GA release matters for any team that uses GitHub for Windows, .NET, Azure or other development. It adds changes to approvals, signing, merge queues and automation.

What a stack is​

GitHub's documentation describes a stack as two or more pull requests in the same repository. The bottom pull request targets the trunk, usually main. Each later pull request targets the branch of the one below it. Foundational changes, such as shared types and database schema, go in lower branches. Code that depends on them, such as API routes and UI components, goes in higher branches.
Reviewers get a smaller diff for each layer. Developers can keep building on top of work that hasn't merged yet.
The usual reason given for this is AI-assisted coding. InfoQ framed the feature as a way to balance faster code generation, especially AI-assisted code generation, against limited human review capacity.

What GA adds​

GitHub's changelog lists these changes:

• Approvals survive rebases. When the base branch such as main moves ahead and the stack is otherwise unchanged, Rebase stack keeps approvals. This holds even in repositories that dismiss stale approvals.
• Signed replacement commits. Rebase stack creates signed replacement commits and preserves the original authorship. Automatic rebases after a partial merge also sign the replacements. That happens when branch rules require signatures or when any original commit was signed.
• Bypass permissions. Users who are allowed to bypass repository rules can use that permission to merge the lowest unmerged pull request in a stack.
• Merge queue behavior. A stack enters and lands through the merge queue as a single merge group. With the merge-commit method, GitHub now creates one merge commit per pull request. Before, it created one for the whole group.
• Deleted base branches. GitHub retargets the stack automatically instead of closing the bottom pull request. This supports workflows where one stack branches off another.
• Auto-merge. Stacks can be set to merge once the repository's requirements are met. GitHub says this is rolling out over the next few weeks, so don't assume it is on for your account today.
• Navigation and visibility. Stack details now sit in the pull request page's persistent header and in the pull requests list view. Shift+J and Shift+K move between pull requests in a stack.
• Lifecycle events and webhooks. The timeline shows when a pull request is added to or removed from a stack. The pull_request webhook gains a stacked action when a pull request joins a stack.
• CLI and agents. The gh stack extension for GitHub CLI now supports Git worktrees. GitHub also cites faster initialization, checkout and navigation.

How merging works​

These details come from GitHub's merge documentation.

• Bottom-up only. You can merge any contiguous group that starts at the lowest unmerged pull request. A mid-stack pull request can't merge on its own, because everything below it merges with it.
• Requirements. All lower pull requests must be approved and have passing checks. The stack must have a linear history, and the pull request must meet the branch protections for the stack base.
• Non-linear stacks. If a lower branch changed or the trunk moved ahead, a Rebase stack button appears in the merge box.
• After a partial merge. The next unmerged pull request is automatically rebased to target the base directly.
• Merge queues. Pull requests enter the queue in order. If one is ejected, everything above it is removed too. The queue may exceed its configured maximum group size by up to 50% to keep a stack together. A stack too big for that buffer goes into the next merge group as a single unit.

The merge documentation retrieved during research still says auto-merge is not supported for stacks. That conflicts with the GA changelog. The likely explanation is that the docs haven't caught up with the staged rollout. Treat the changelog as the newer statement, and check your own repository before relying on it.

Automation and API notes​

GitHub's async merge API, which went GA on October 1, is now the recommended way to merge pull requests programmatically. It is also the only merge API that supports stacked pull requests. Scripts that call the legacy synchronous merge endpoints or GraphQL mutations can't merge a stack.
GitHub's API documentation adds several details:

• The merge runs in the background, and callers poll for the result.
• Branch protection and repository rules are evaluated when the merge actually runs. A rule failure shows up as a failed result while polling.
• A stack merge request is atomic. The whole group merges or is queued, or none of it is.
• The REST API can read and manage stacks. GraphQL is read-only for them.

The CLI docs add a few more points:

• gh stack merge is all-or-nothing.
• Branch protection is evaluated at merge time, and any failure is reported back.
• If the base branch uses a merge queue, the queue chooses the merge method.
• The CLI reference notes that merge requirements can't be bypassed through the CLI. The changelog says bypass permissions now apply to stacks, so check the CLI's behavior yourself before relying on bypass there.

Limits to check first​

• Same repository only. Cross-fork stacks aren't supported. The roll-out guide also says stacks can't include forks or branching structures. Teams that depend on fork-based contributions should keep that work outside stacks.
• No GitHub Desktop. Support is listed for the website, GitHub CLI, GitHub Mobile, webhooks, REST, GraphQL and an agent skill.
• Merge-method caveat. One third-party summary of the preview, from AlphaSignal, advises repositories that default to squash or rebase merging to consider merge commits. It says stack identity tracking can break otherwise. GitHub's docs say stacks support all three merge methods, so test this on a non-critical repository.
• Enterprise Server. GA applies to github.com plans. GitHub says only that the feature will be in an upcoming GitHub Enterprise Server release, with no version or date.
• Docs still say preview. Some GitHub guides retrieved during research still carry public-preview notices. The dated changelog is the authority for the GA claim.

Reading GitHub's numbers​

GitHub says that since the preview began, repositories using stacks saw a 9% increase in merged code compared with peers. It also says over two-thirds of the top 1% of repositories now use stacks and saw a 5% improvement in time-to-merge.
These are GitHub's own figures. The announcement gives no measurement period, sample size or definition of "peers". Heavy users of any new workflow tend to be the busiest teams anyway, so cause and effect is unproven. Merged code volume is also not the same as quality.

Practical impact​

The most useful changes for enterprise admins are the ones that stop stacks from fighting repository rules. Approvals that survive a rebase, signed replacement commits and per-pull-request merge commits all keep the audit trail intact. Teams with strict compliance rules were the likeliest to be blocked by earlier behavior.
Developers who use third-party stacking tools should compare them against the native version. Their mechanics now overlap with GitHub's. A DEV Community write-up argues the native feature covers the core mechanics. It says third-party tools still differ on polish, cross-repo workflows and team features. That is one commentator's view.
A cautious way to start:

1. Try a small stack on a low-risk repository with your real branch protections.
2. Confirm that CODEOWNERS and required checks behave as you expect on mid-stack pull requests.
3. If you use a merge queue, check how a stack sits in it.
4. Update any merge scripts to use the async merge API.
5. Wait for auto-merge to reach your account before building a workflow around it.