❌

Reading view

Visual Studio Code 1.136 introduces agent merges for pull requests

Microsoft has released Visual Studio Code 1.136, an update to the popular programming editor that previews an Agent Merge feature and introduces two experimental features for agentic coding.

VS Code 1.136 was released September 2 and can be downloaded from code.visualstudio.com.

Agent Merge, a preview feature, helps take a pull request across the finish line, Microsoft said. Agent Merge asks an agent to address review feedback, fix failed checks and merge conflicts, and rerun workflows until the pull request is ready to merge. To use Agent Merge, turn on the setting chat.agentMerge.enabled. Then you can enable Agent Merge for a session by running “Enable Agent Merge for Active Session” from the Agents window or selecting the “Agent Merge” button in the title bar.

VS Code 1.136 also introduces multi-root workspaces, an experimental feature that allows developers to work with GitHub Copilot and Claude agents across multiple project folders in the editor window chat view. Agent hooks remain scoped to a single workspace folder, Microsoft said. If hooks are detected in multiple folders, VS Code prompts the user to select the primary folder from which to load them.

Another experimental feature in VS Code 1.136 is chat backgrounds in the Agents window. This allows users to personalize the Agents window with a theme-aware pattern of built-in VS Code icons or an image of their own. Also new for chat are enterprise controls for dictation data. The new controls allow administrators to manage the dictation model and language-model transcript cleanup through enterprise policies. Microsoft said it was possible to require on-device transcription and disable language-model cleanup, so dictation remains available while preventing dictation data from being sent to cloud transcription or a Copilot model.

  •  

Preparing to Update to Golden Gate

Howard Oakley:

As those new models start shipping on 22 September, the window for the first public release of Golden Gate has narrowed to 15-22 September, with greatest likelihood on the same day as the arrival of those new Macs.

[…]

At the same time as the release of Golden Gate, we should get Tahoe 26.7 and Sequoia 15.8, but it looks increasingly likely that the final version of Sonoma has been 14.8.9, released on 6 August.

Howard Oakley:

As we prepare to flee from the visual horrors of macOS Tahoe at last, this article is a reminder that it wasn’t the first major release of macOS that has had blatant bugs in its interface, although I suspect it may be unique in that those were intentional. While progress in Golden Gate has been limited, I hope you’ll find it rectifies some of the worst errors of Liquid Glass.

Many Macs will be left behind, as Golden Gate drops support for Intel.

Normally, I update around January. With Tahoe I waited until July. This time, I’m considering updating to Golden Gate soon after its release. The downside is that Xcode 26 doesn’t run on Golden Gate, so I would have to drop support for many older macOS versions (about 3% of my customers’ Macs). But it seems like Apple’s going to force that soon, anyway, as one of the next Xcode 27 updates will likely drop support for Tahoe. I want to get off Xcode 26, both to use the newer SDK and because there are various debugging/testing things that don’t work properly.

Mario Guzmán:

I am working on a new app. Right now, I am targeting back to macOS Sequoia. I think that would be a good OS to target but becoming quite old with Golden Gate just around the corner. […] I wonder if I should just target macOS Golden Gate and focus testing on that.

Previously:

Update (2026-09-04): Isaiah Carew:

i’m in the exact same boat. i’d really like to stay on macOS 15 and whatever Xcode works there. it means i can still build things in the old UI and mostly Tahoe and GG respect it.

but recent bug reports from beta testers and the inability to see these bugs on my VM has made me feel very stuck here — like apple has purposefully made it difficult to move forward and support older versions too.

Update (2026-09-11): Howard Oakley:

What if any preparations do you need to make before upgrading or updating then, or in the coming weeks?

Update (2026-09-16): Adam C. Engst:

So who should upgrade immediately, and who should wait? Let’s consider a few broad categories of users.

  •  

Ending the Golden Era for Backward-Compatible Apps

Matthias Gansrigler-Hrad:

I don’t appreciate being forced by Xcode 27 to drop support for macOS 10.13-11.0. It’s my decision which OSes I want to support, not Apple’s. Yes, I can keep Xcode 26 around until submissions require Xcode 27, but what then?

Originally, Xcode 27 was documented as supporting Big Sur on Intel Macs, but now the earliest is Monterey.

I’m frustrated, too, but it’s more honest than the recent releases that claimed to support deployment on older macOS versions when Apple clearly hadn’t tested that it actually worked. I filed bugs, and Apple kept responding that they’d fixed it, when they hadn’t.

Using old versions of Xcode isn’t a great solution because they aren’t supported on Golden Gate. Swift also makes it more difficult to call newer APIs when using an older SDK. You can’t just copy/paste a method prototype or constant value and conditionally use it when running on a newer OS.

Ighor July:

I eventually found a hidden workaround that changes the errors back into warnings. That is good news, but it does not make the concern disappear. The setting is undocumented, absent from the normal Xcode interface, and currently being tested only in a beta toolchain. The larger question is what Apple intends to enforce when Xcode 27 is final and, later, when App Store submission requirements move to its SDKs.

[…]

Apple’s current Xcode system requirements list Xcode 26 with deployment targets beginning at iOS 15 and macOS 11. Yet developers have been able to enter older targets manually. In an Apple Developer Forums discussion about Xcode 26, an Apple product manager explained that the published deployment target range is aligned with simulator support and on-device debugging. The accepted answer confirms that an iOS 13 target can still build even though it falls below the range in Apple’s table.

My own tests went further. Xcode 26.5 compiled a project targeting iOS 9.0. It warned that the target was older than the supported range, but the build succeeded. On macOS, I have compiled current apps with deployment targets as old as macOS 10.9. Xcode warned me, but it still produced working applications.

[…]

For iOS and iPadOS, staying on Xcode 26 is not a lasting option. Apple has repeatedly made a current Xcode and SDK mandatory for new App Store submissions. […] If any one of those conditions fails, iOS and iPadOS developers will have no normal App Store path for publishing new updates that still support versions older than 15.

Previously:

Update (2026-09-07): Léo Natan:

Just want to remind you guys that if you move to Xcode 27, the only “officially” supported and sanction Xcode for GG, UIDesignRequiresCompatibility is no longer respected across the 27 OSes (apps built with older Xcodes still are). So you might suddenly find out you have a lot of work ahead of you, adding support for the dreaded Glass. And 27 Glass is not the same as 26 Glass. That can be an issue if you skipped 26 altogether but still want to support it.

Previously:

Update (2026-09-11): Nick Lockwood:

I mostly ignored the Xcode 27 betas (mainly due to the barely-usable Device Hub) so I didn’t realize the passive-aggressive prompts to drop support for iOS < 15 that you get when submitting apps is being backed up by Xcode 27 refusing to compile apps at all unless you bump the deployment target 😧

  •  

MacVoices #26246: Democratizing Programming: From HyperCard to Claude with Adam Engst (1)

Adam Engst looks back at HyperCard as an early tool that democratized software creation, then connects its legacy to today’s AI-assisted development. He outlines how Claude helped turn an idea for tracking macOS setting changes into a working Mac app, SetShot. Adam discusses Xcode, GitHub, rapid iteration, and the value of visual feedback in his development process, and how AI lowers programming barriers without eliminating the need for thought, judgment, and effort. 

💾

💾

  •  

Researchers get two genetic codes to work at the same time

The genetic code is what life everywhere uses to convert the information contained in DNA into specific protein sequences. With minor variations, the same genetic code is used by every living thing on Earth, suggesting it was already present in the last common ancestor of all of them. It's not an easy thing to change, because so many things in every cell depend on it.

Nevertheless, some preliminary steps have been taken. Researchers have managed to add some new amino acids to a bacterial cell and were able to make proteins that were one amino acid less than usual. But it's a slog; for some of this work, people have had to re-engineer every single gene in a bacterial genome.

Now, researchers have found a way to operate two separate genetic codes simultaneously, avoiding the need to do any work to compensate for altering the code that every protein in a cell relies on. They didn't test it in an actual cell, and it might cause some problems there. But it's a creative solution that should accelerate some synthetic biology work.

Read full article

Comments

© ALI DAMOUH/SCIENCE PHOTO LIBRARY

  •  

Sudoku in Turing-Complete Unicode Transliteration Rules

Nicolas Seriot (Hacker News, Reddit):

The core Unicode algorithms (normalization, casing, bidi, collation) are deliberately bounded, but UTS #35 transliteration rules, under their natural unbounded semantics, are not. This is a result I haven’t found published before.

These rules ship as locale data in ICU, the Unicode library shipped in operating systems, browsers, runtimes, and databases. Whether a given rule file terminates on a given input is undecidable.

[…]

To prove UTS #35 universality, we compile 2-tag systems (Post, 1943), a model proven universal (Cocke & Minsky, 1964), into transliteration rules.

[…]

Transliteration rules were designed to turn “é” into “e”. Three lines of them can compute the Collatz function.

KT_Music:

Inspired by this, I tried creating an implementation that “solves #Sudoku” using only UTS#35 transformation rules 😎

Previously:

  •  
❌