Google Wants to Update Chrome Without Making You Restart It

Google is building a way for Chrome to update itself without requiring a full browser restart, part of a broader plan to speed up how often the browser gets fixes starting in September. The Verge
The plan starts with moving Chrome to a two-week major release cycle, with security updates slotted between those releases. Google is also considering adding two security updates per week on top of that schedule. The company says this is a direct response to fast-moving attacks powered by AI. The concern is that attackers using AI tools can now find and exploit software flaws faster than a weekly update can keep up with.
The system Google is working on, called "dynamic patching," would let Chrome apply code changes to the browser while it is still running, without the disruption of closing and reopening it. Chrome 150 on Mac already takes a partial step in this direction. When the browser detects it is running in the background with no open windows, it can restart itself automatically to apply updates. Google's long-term vision is a browser that stays continuously up-to-date through a combination of dynamic patching and automatic restarts timed for moments when users are least likely to be disrupted.
The numbers behind this push are striking. Chrome versions 149 and 150 together included 1,072 bug fixes. That is more than the total across the previous 23 major releases combined. Google has said that AI-powered security tools helped the company find and fix dozens of those bugs. The company has not said whether AI-assisted discovery is the main reason for the increase or just one of several factors, but it credits those tools with meaningful output.
Together, a shorter release cycle, possible twice-weekly security updates, and dynamic patching point to a browser designed to update almost constantly. For IT staff who manage Chrome across large organizations, a two-week major release schedule with security updates in between changes how they test and approve new versions. Companies that already struggle to keep up with Chrome's current four-week cycle will have even less time to check that new updates do not break existing software before those updates roll out widely.
The broader context here is an arms race between attackers and defenders. Google's stated reason for considering twice-weekly security updates is the speed of AI-powered attacks. If attackers can use AI to go from finding a flaw to exploiting it faster, then the pace of defensive updates has to speed up to match. This is a real-world example of the AI security conversation that has dominated the tech industry for the past two years, now showing up as a concrete change in a product people use every day.
The dynamic patching work is the harder technical challenge. A running browser is complex: it splits work across multiple processes, compiles JavaScript code on the fly, and manages graphics through the computer's GPU. Patching all of that without restarting is far more difficult than restarting a browser that is running quietly in the background. Google has not said when dynamic patching might be ready. The Mac background-restart feature in Chrome 150 is a practical step that captures update chances users would otherwise miss, but it is not the same as fixing a browser while someone is actively using it.
For everyday users, the stakes are simple. Chrome has always downloaded updates quietly in the background and then asked the user to restart. Many people put off that restart for days or longer. Anything that reduces the need for a user to manually restart, whether through background restarts or dynamic patching, shortens the time a known security flaw stays unfixed on a live computer. The 1,072 fixes in versions 149 and 150 show that producing patches is not the problem. Getting them installed is.
Google's stated goal is a browser that is always up to date through a combination of dynamic patching and well-timed restarts, which would effectively remove the user from the update process entirely. Whether the engineering challenges of patching a live browser can be solved cleanly enough to reach that goal is an open question. The direction, though, is clear: shorter update cycles, more frequent security fixes, and fewer restart prompts.


