JetBrains is warning of a critical security vulnerability in its TeamCity DevOps platform that could allow unauthenticated attackers to execute arbitrary operating system commands on vulnerable servers.

“If exploited, this vulnerability may allow an unauthenticated attacker with HTTP(S) access to a TeamCity server to bypass authentication checks and execute arbitrary commands,“ the company said in a security advisory.

The flaw, tracked as CVE-2026-63077, affects all TeamCity On-Premises deployments and has been fixed in versions 2025.11.7 and 2026.1.3.

JetBrains warned that the flaw potentially exposes build environments, stored credentials, and software supply chains. Customers unable to upgrade are advised to deploy a security patch plugin immediately.

TeamCity Cloud customers are not required to take any action, the company reassured.

RCE achieved without authentication

According to JetBrains, the vulnerability resides in the TeamCity agent polling protocol, allowing an attacker with HTTP(S) access to bypass authentication and execute code with the privileges of the TeamCity server process.

The vulnerability carries a CVSS score of 9.8 out of 10 as it requires no authentication or user interaction, making internet-exposed TeamCity servers particularly attractive targets. Classified under CWE-502 (deserialization of unstructured data), the flaw can be used to send specially crafted data through the affected agent polling protocol to trigger remote code execution (RCE).

“Depending on the privileges granted to the TeamCity server process, a successful attack could expose TeamCity data, configurations, and stored credentials, modify server state, and potentially compromise the integrity of build artifacts and downstream CI/CD pipelines,” the company added.

The issue was privately reported on July 10 by security researcher Antoni Tremblay through JetBrains’ coordinated disclosure process.

JetBrains said it had found no evidence of active exploitation at the time of publishing the advisory.

Developers have two mitigation paths

JetBrains is recommending that customers upgrade directly to TeamCity 2025.11.7 or 2026.1.3, both of which include a permanent fix for the vulnerability.

Organizations unable to upgrade immediately can instead deploy a security patch plugin, which is available for TeamCity versions 2017.1 and later. Servers running versions 2017.1 through 2018.1 require a restart after installing the plugin, while newer supported releases can enable the fix without restarting, the company added.

The company also advised administrators whose TeamCity servers are publicly accessible to restrict external access if neither mitigation can be applied immediately.

“As a general best practice, we strongly recommend limiting network access to TeamCity servers to trusted networks wherever possible,” the company said. “We also recommend running the TeamCity server with the minimum operating system privileges required for normal operation.”

Given the vulnerability’s pre-authentication nature and the history of threat actors rapidly weaponizing TeamCity flaws, organizations running self-hosted CI/CD infrastructure are advised to prioritize emergency patching over routine maintenance windows.

The advisory also recommended running TeamCity servers on dedicated hosts separate from build agents, as per official instructions.

The article originally appeared on CSO.

A critical vulnerability in the open-source AI agent platform Ruflo could allow unauthenticated attackers to take control of enterprise AI environments by exploiting an exposed Model Context Protocol (MCP) bridge, according to research published by Noma Security.

The flaw, tracked as CVE-2026-59726 and dubbed RufRoot, carries a maximum CVSS score of 10.0 and affects Ruflo versions prior to 3.16.3, Noma Security wrote in a blog post.

The vulnerability allows attackers to execute arbitrary code, steal large language model (LLM) API keys, access user conversations, hijack AI agents, and manipulate the platform’s persistent AI memory through a single HTTP request.

The researchers said the issue stems from an unauthenticated MCP Bridge that is exposed by default and provides direct access to the tools AI agents use to interact with enterprise systems.

“The MCP Bridge isn’t a random auxiliary debug interface; rather, it is Ruflo’s central nervous system. Every tool call, every agent action, every memory operation goes through the MCP bridge,” the researchers wrote. “Mistakenly giving unauthenticated access to the MCP Bridge means giving unauthenticated access to everything.”

One request leads to full compromise

According to Noma Security, Ruflo’s built-in MCP Bridge is an Express.js server that handles every tool invocation made by AI agents. The bridge exposes 233 tools covering shell access, database operations, agent management, and memory storage.

The researchers said the bridge’s /mcp endpoint accepts tool invocations without authentication. In a proof-of-concept demonstration, they used Ruflo’s terminal_execute tool to obtain command execution inside the container with a single HTTP request.

“Because the MCP Bridge requires direct access to the underlying system resources to execute these commands, it creates a high-stakes security boundary,” the researchers wrote. “When an attacker can reach this endpoint without authentication, they gain a direct pipeline to the underlying host infrastructure.”

The researchers said they were able to enumerate available tools, steal LLM provider API keys from environment variables, deploy attacker-controlled AI agent swarms, retrieve user conversations stored in MongoDB, and establish persistence.

The researchers also demonstrated what they described as AI memory poisoning by inserting malicious entries into Ruflo’s AgentDB pattern store, allowing future AI responses to incorporate attacker-controlled instructions.

Every stage of the attack chain was validated against a default Ruflo deployment running on AWS EC2, according to the researchers.

Beyond Ruflo: A broader MCP security challenge

While the authentication flaw is specific to Ruflo, security practitioners say the research highlights broader risks surrounding AI orchestration platforms and MCP infrastructure.

“MCP adoption has outpaced the security defaults built into a lot of orchestration tools,” said Amit Jena, AI Development Manager at Kanerika. “These platforms shipped fast, prioritized ease of setup over authentication, and assumed the network boundary would protect them. That assumption breaks down once the tool sits on a server reachable from a corporate network, which is increasingly where enterprises are running them.”

Jena said the research also points to a security concern that extends beyond a single product.

“The memory poisoning problem isn’t product-specific, and that’s the part worth paying attention to,” he said. “Any platform that gives agents a persistent, writable memory store needs to treat that store as a security boundary: who can write to it, and can you tell system-generated memory from memory an attacker planted. Very few platforms are doing that today.”

He added that, unlike traditional persistence techniques, poisoned AI memory can remain inside a trusted data store and continue influencing future agent behavior after the original intrusion has ended.

Patch addresses attack chain

Noma Security said it disclosed the vulnerability responsibly to Ruflo, which released fixes within hours along with a public security advisory.

According to the researchers, the updated release changes the MCP Bridge to bind to the loopback interface by default and fail closed if administrators attempt to expose it publicly without configuring authentication.

Noma Security also urged organizations running Ruflo to immediately close firewall access to ports 3001 and 27017, rotate all LLM API keys, audit AgentDB for malicious entries because “a patched redeploy alone doesn’t undo poisoning,” and inspect MongoDB for signs of tampering.

Jena said organizations should also review how AI orchestration platforms are deployed and managed.

“If a component can execute a shell command or query a database, it gets the same authentication, network segmentation, and logging as any other privileged system in the environment,” he said. He also recommended that security teams inventory the tools exposed through AI agent deployments, audit persistent AI memory separately from software patching, and narrowly scope and rotate LLM provider credentials following any suspected exposure.

The article originally appeared on CSO.

One percent of AI-active developers now generate 46 times more AI-written lines of code per day than the median active user, according to the Cursor Developer Habits Report. The bottleneck is no longer writing software. It is understanding what happens after that software ships.

Every new service, dependency, feature flag, generated abstraction, and deployment path increases the number of ways a production system can fail. AI has compressed the time it takes to create that complexity. It has not compressed the time it takes to understand it.

The result is a production environment that changes faster than engineers can rebuild a mental model of it. AI can help in this situation because most debugging practices were designed for a slower world.

Debugging yesterday and today

For decades, debugging was largely a spatial problem. A failure in Service A belonged to the team that owned Service A. They knew the deployment history, the operational quirks, the useful log queries, and the odd behaviors that never made it into the runbook. Incident response reflected that assumption. Teams owned services. Runbooks were scoped to those services. On-call rotations mirrored organizational boundaries.

That model still works when failures stay local. If a deployment introduces a memory leak, or a bad configuration causes a service to crash, the symptom and the cause usually live in the same place. The owning team can investigate, identify the issue, and restore service. Those incidents are becoming a smaller share of production failures.

AI-generated code is not inherently less reliable than human-written code. The change is volume and speed. Teams can now introduce more code, touch more systems at once, and evolve architectures faster than before. As systems become more interconnected, failures increasingly surface somewhere other than where they start.

A single-hop incident is local. The service experiencing the failure is also the service causing it. Investigation stays inside one team’s boundary.

A multi-hop incident looks different. The checkout API begins timing out. Nothing appears wrong inside checkout. Latency is normal. Error rates are low. The actual problem is a queue consumer silently dropping messages because a schema change deployed two days earlier was only partially backward compatible. The queue team sees healthy throughput. The data platform team never receives a page because nothing in its service violates an alert threshold. Every team is right about its own system, yet nobody can explain why customers cannot complete purchases.

The problem is not a lack of evidence. Modern production systems produce more telemetry than any human can use during an incident. The problem is knowing which evidence matters, which signals are coincidental, and how separate clues connect into a causal chain.

The role of AI in production ops

That changes the role AI should play. AI should not be treated as a magic on-call engineer. A frontier model does not know your architecture. It does not remember prior incidents. It does not know which dashboards lie, which services fail together, what changed last week, or which dependencies matter most. On its own, it reasons inside a vacuum.

The useful version of AI in production is more specific. It can assemble context, test hypotheses, trace dependencies, compare the current incident against past incidents, and rule out explanations that do not fit the timing or blast radius. It can do the work that currently eats the first 20 minutes of an incident: gathering evidence, checking recent changes, mapping dependencies, and narrowing the search space.

Humans still make the decisions that require judgment. They decide whether the evidence is strong enough to act, whether a rollback is worth the risk, whether to wake another team, and whether the safest move is mitigation or deeper investigation. But they should not have to spend half the incident reconstructing a system the organization already operates.

That is the larger productivity shift.

If AI can absorb more of the troubleshooting tax, engineers can focus on the work that actually compounds. They can simplify fragile architectures. They can improve instrumentation in the places where incidents repeatedly go dark. They can design safer degradation paths, sharper alerts, better rollback patterns, and evals that catch semantic failures before customers do. They can feed production knowledge back into development, so code assistants and review processes understand which services are risky, which patterns have caused outages, and which dependencies deserve extra scrutiny.

This is the work engineers rarely get enough time to do because they are stuck resolving the same classes of incidents again and again.

Letting the engineers engineer

The goal is not to remove engineers from production. The goal is to stop wasting their judgment on work the system should already be doing. AI should make incidents shorter, but that is only the first-order benefit. The larger benefit is giving senior engineers more time to prevent future incidents instead of being pulled into every confusing one.

As AI accelerates software creation, production operations need the same kind of acceleration on the other side. Not just faster debugging. Better allocation of human attention.

The AI code avalanche will not be managed by asking engineers to troubleshoot forever at machine speed. It will be managed by making production systems more legible, more resilient, and less dependent on whichever expert happens to be awake.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

Microsoft has shipped Visual Code 1.131, an update to its code editor with improvements for monitoring subagents, dictation, and Markdown editing.

Released July 29, Visual Studio Code 1.131 can be downloaded for Windows, Linux, or Mac at code.visualstudio.com.

An enhancement to the Agents window in VS Code 1.131 allows developers to see what a running subagent is doing without opening its conversation. For each subagent, the main conversation now shows the model used by the subagent, how long the subagent has been running, and the tool the subagent is actively calling.

A preview of built-in dictation across VS Code gives developers dictation capabilities without having to install the VS Code Speech extension. The transcription service works in chat inputs, text editors, and the terminal, Microsoft said. A single speech session and microphone selection are shared across all three surfaces, which prevents overlapping recordings and keeps dictated text in the intended location, according to the company. This is an experimental feature.

VS Code 1.131 also introduces a hybrid Markdown editor in the Agents window, allow users to view Markdown files, edit them in place, and add comments that an agent can act on. By using “Reopen editor with”, developers can switch easily between the text editor and the new Markdown editor, both in the Agents window and editor windows. The hybrid Markdown editor is an experimental feature.

For accessibility, screen reader users now can read terminal output at their own pace while commands continue to produce output. Set terminal.integrated.accessibleViewPreserveCursorPosition to always preserve the cursor position in the terminal Accessible View, including when new content arrives. Existing true and false values continue to work. Terminal live updates also use a non-interrupting ARIA status announcement instead of an assertive alert. Output remains available to screen readers without repeatedly interrupting other speech.

VS Code 1.131 followed VS Code 1.130 by one week. VS Code 1.132 should arrive soon.

Model Context Protocol (MCP), the emerging standard for connecting AI models to external tools and enterprise data, is undergoing its biggest architectural overhaul yet.

The latest release candidate, scheduled for release on July 28, removes protocol-level sessions in favor of a stateless architecture, a change which industry experts say is intended to make MCP easier to deploy across standard cloud infrastructure as enterprises move AI pilots into production.

“The session-based model made sense when MCP servers were local processes on a developer’s laptop. In production, it became an operational tax,” said Muskan Bandta, cloud associate at ZopDev.

“When your infrastructure team asks whether MCP services can scale like other cloud applications, the answer used to be ‘not quite.’ With the move to a stateless architecture, the answer is now yes,” Bandta added.

Earlier versions of the protocol maintained information about every client connection, meaning servers had to keep track of each session throughout an interaction. While that approach worked well for local development, it complicated deployments across multiple servers because requests often had to be routed back to the same machine, limiting scalability and making MCP a less natural fit for modern cloud architectures.

“Under the new stateless design, every request contains the information needed for any available server to process it independently. Applications that need to maintain context across multiple requests can still do so, but developers must now manage that state explicitly rather than relying on the protocol itself,” she said.

This transition to a stateless design goes beyond simplifying infrastructure by fundamentally changing how AI applications manage and share context across tools, according to Amit Jena, AI development manager at IT consulting firm Kanerika.

Instead of keeping application state hidden inside protocol sessions, the new design makes it explicit, allowing AI models to access, reason over, and pass that information between tools, giving developers greater control over how context is preserved and shared across tools, Jena said.

It should also make AI workflows more portable, resilient, and easier to orchestrate across distributed environments, he said.

MCP’s new features

Other changes to MCP include the addition of a Multi Round-Trip Requests (MRTR) mechanism that changes how AI agents request additional information they need to complete a task.

Instead of relying on a persistent connection between the client and server throughout the interaction, the new mechanism lets the server request additional input through a standard request-response exchange before continuing the task, Jena said.

Routable transport headers, another addition, enable API gateways and other networking infrastructure to identify and route MCP requests without inspecting their contents.

They reduce processing overhead, lower latency, and let enterprise teams enforce routing, rate-limiting and security policies more efficiently using existing API management infrastructure, Jena said.

MCP is also getting an updated authorization framework built around OAuth 2.1 and OpenID Connect; interactive MCP Apps; and deterministic caching of tool and resource listings to improve LLM prompt-cache hit rates, potentially saving on token costs.

Rebuilding the trust boundary

The MCP release steering committee also decided to deprecate some legacy features, including Roots, Sampling, Logging, the older HTTP+SSE transport and Dynamic Client Registration, although these will continue to work in this version and any other released over the next year.

The deprecation of Sampling is likely to have the biggest impact because it changes who is responsible for interacting with foundation models, said Jena.

“Sampling let MCP servers invoke the LLM through the client, which meant the server had a callback path into the model without owning that connection. Deprecating it means rebuilding that trust boundary,” Jena said. “Your server now calls the model provider directly. That changes your network architecture, your auth model, and depending on how you’ve built cost attribution, your billing flow.”

The year-long transition period will be enough for teams to audit their sampling dependencies now, said Jena: “The risk is that teams who haven’t implemented sampling themselves won’t know if a third-party MCP server they’re depending on uses it.”

Updated MCP SDKs

To accompany the protocol update, there are updated MCP SDKs for Python, Typescript, Go, and C#. These support both the old and new protocol versions, so new clients can continue communicating with older servers, while updated servers will also support older clients, reducing the risk of immediate disruptions.

That backward compatibility should make the transition largely incremental, except for enterprises that built custom infrastructure around MCP’s earlier session-based architecture, Bandta said.

Identifying and auditing those session dependencies may not be easy, Jena warned.

“Session management complexity tends to be hidden across multiple layers — the gateway config, the deployment scripts, the monitoring dashboards. The code change is small; finding everywhere the assumption lives is what takes time,” he said.

Enterprise software developers continue to be in danger of falling victim to slopsquatting, where AI coding tools hallucinate the existence of nonexistent libraries and hackers create malicious packages in response.

The top AI coding tools are remarkably consistent in their hallucinations: Researcher Aleksandr Churilov found the same 127 fake package names generated by five different LLMs.

Slopsquatting is a relatively new form of malware attack that involves the creation of malicious packages in response to the hallucinations of AI coding tools, causing the malicious packages to be incorporated into legitimate applications.

Churilov set out his findings in a research paper, The Range Shrinks, the Threat Remains: Re-evaluating LLM Package Hallucinations on the 2026 Frontier-Model Cohort, which is yet to be peer-reviewed. He found 127 hallucinated package names were shared across Claude Sonnet 4.6, Claude Haiku 4.5, GPT-5.4-mini, Gemini 2.5 Pro, and DeepSeek V3.2.

 As of April this year, 53 of those names — 41 on the PyPI software repository and 12 on npm —are still available for registration.

According to the study, there are two reasons for this amount of conformity in the output of the models. First, models may learn the same incorrect package references from shared public training material, such as tutorials and documentation.

Second, they may independently extrapolate plausible names from ecosystem conventions. In this way, they could produce names that look correct, even if they don’t actually exist.

While Churilov’s research will worry CISOs and security-conscious developers, there is some relief. The research has not yet found any evidence that any of the remaining 53 names have been registered maliciously, nor used in an attack.

Microsoft has released Visual Studio Code 1.130, an update to the code editor that brings several improvements to the Agents window, along with enhancements to the agent host and the terminal.

VS Code 1.130 was released on July 22, one week after VS Code 1.129. Developers can access the release for Windows, Linux, or Mac from code.visualstudio.com.

With the new release, the Agents window gets updates that make it easier to review changes and manage chats. File-level diff statistics help users assess the size of each file’s changes when scanning a multi-file diff. The window also gets a more compact multi-file diff that makes it easier to review changes, Microsoft said. The Agents window is a dedicated window in VS Code that lets users run and track multiple agent sessions in parallel across their projects, without opening each workspace in a separate window.

Also with VS Code 1.130, assisted permissions for agent tool calls are available in the agent host. With assisted permissions, the LLM evaluates the risk of each tool call and decides whether the tool can run or should require the user’s approval. The setting to enable assisted permissions is chat.assistedPermissions.enabled. In another agent host improvement, quick chats running on the agent host now use compact, single-line rows in the sessions list. Regular sessions retain a second line with change statistics, status, and timestamps.

VS Code users now can open file links from Git diff output in the terminal when Git’s diff.mnemonicPrefix option is enabled. VS Code recognizes prefixes such as i/ for the index and w/ for the working tree, and removes the prefix from the link target so the correct file opens. When mnemonic prefixes are enabled, VS Code also recognizes the numeric prefixes produced by git diff --no-index.

Timestamps for chat requests and responses now are displayed when users hover over the message toolbar. You can disable this through the chat.verbose setting.

Running containers on Windows has never been as easy as it should be. While there are versions of Docker Desktop and Podman that work with both the Windows Subsystem for Linux (WSL) and Hyper-V, I’ve found both overly complex and unstable. Where they have worked, it’s turned out that Hyper-V has been the best option, using a Linux virtual machine to host my containers. That all adds up to overhead, layers of virtual infrastructure that get in the way of work and that need to be rebuilt every time I restart my PC.

Part of the problem is WSL. It’s a good tool, but WSL2’s file-system integration is slow, and you’re left having to work with code using Visual Studio Code’s remote integration, which means putting a VS Code Server in every container you’re building and testing. If you’re working with Kubernetes, that’s even more complexity that needs to be managed, dragging you away from code.

I ended up running most of my container testing and development from a separate machine, a Linux server running containerd. But though it worked (and had all the resources of workstation-class device), it wasn’t portable, and for some reason I’ve yet to uncover, Ubuntu’s remote desktop access doesn’t work for me.

So, it was good to see Microsoft make several announcements around WSL at Build 2026 as part of a push to make Windows a developer platform again. The first, an improved WSL3, is still some way away, but the second, WSL-native container support, shipped at the end of June. It is already seeing community-driven development of Docker Desktop-like tooling to help monitor and manage your containers.

Delivering a WSL-based container platform fits in with the other developer-focused Windows announcements at Build. Making Windows behave more like Linux is Microsoft responding to developer needs, given that more than 50% of servers on Azure run a Linux distribution. Linux is the basis of cloud-native infrastructure, so developers need to be able to build on it wherever they are.

Getting started with WSL container

WSL container provides a new CLI that works in parallel to the familiar WSL, with commands to support the entire container life cycle, from creation to shut down. All you need to do to get started is upgrade your WSL installation to the current pre-release build (at the time of writing this was 2.9.3). Simply open an administrator PowerShell terminal and enter wsl --update --pre-release.

This downloads and installs the latest WSL release. Once you’ve closed and re-opened your terminal (to ensure that you’ve updated its context) you can check that WSLC has installed by entering wslc, which should list the available commands. The new CLI is aliased to WSL container, if you prefer to keep your container work separate from WSL (and avoid typos that might accidentally affect your WSL installations).

Under the hood Microsoft is using WSL container to trial new integration points for Linux in Windows. One key change is the use of a new file system that significantly speeds up access to Windows from inside a container. Another improvement gives WSL container a new networking mode that relays networking connections directly through the Windows network stack, ensuring it has access to the same resources and security as Windows.

Calling Linux containers from Windows applications

Things get more interesting when you start to use the WSL container API from inside your Windows code. Here you can include calls to Linux containers inside your desktop applications, taking advantage of existing services, building and deploying containers from inside your CI/CD pipeline. Using the new file system and networking stack helps reduce the friction that comes with crossing the boundaries between the two platforms.

The WSL container API is available as a NuGet package, with support for C, C#, and C++. It allows your code to start and stop containers, and interact directly with them, sending command-line calls and reading back responses. Where things get interesting is being able to launch a containerized service from your code, exposing its REST or gRPC APIs on a local network port. Microsoft has provided sample code to show you what’s possible at this early stage.

Microsoft is doing something revolutionary here. It’s taking the cloud-native, service-driven model and bringing it into Windows and using it to bridge decades of divergent development. You no longer have to rewrite a service that works on Linux to run in Windows; all you need to do is containerize the service and launch it from the WSL container API. When you’re done, the API will tidy up after you, shutting down the container and reclaiming the memory it used.

It’s important to remember that this is only the first public preview of a rapidly developing platform. There are many opportunities here to, say, build on the syscall translation layer developed for WSL1 to produce a native Windows-to-Linux application integration stack that removes the overhead of using web-based service calls. It will be interesting to see what develops, but this first release is very interesting indeed.

Manage Linux containers from Windows

If you want a Docker Desktop-like experience for building and testing containers on Windows developer hardware, you may not have long to wait. WSL container’s underlying API is already being used to build tools that manage and monitor containers for you. One such tool is the WSL Container Desktop, under development on GitHub. While there aren’t any release builds yet, it’s easy enough to compile and get running by cloning the source repository and building using the .NET CLI. You do need to have the Windows App SDK installed, and some features require access to the Azure CLI.

WSL Container Desktop is built in C#, with a WinUI front end. It’s currently only verified for use on x64, though I was able to compile and run it on an Arm64 PC and use it to test and run containers. Once running, it gives you a well-designed front end for your WSL-hosted containers, showing what’s running and what resources they are using. You can link WSL Container Desktop to container registries, like Docker’s and Azure’s, so you can quickly pull base containers and then use the WSL container environment to add your own code and customizations.

Your main interaction point is the WSL Container Desktop dashboard, which shows what containers are running and their current resource usage. Elements are displayed in cards, taking a cue from Windows’ own user interface and especially from its Settings app. From the dashboard, you can drill down into the available containers, with quick start, stop, and reload options, as well as an extended memory that includes the ability to open a web browser to the appropriate port. I tested this with a container that included an entire KDE webtop, giving me a Linux distro running in a container in my browser.

Other options include a details view that displays current logs and provides tools for inspecting the state of a container. This is the type of tool that comes in useful when debugging and testing container applications, as it can provide insights that the WSL container CLI doesn’t offer. Another option helps you clean up after you’ve downloaded an image and don’t need it anymore, with analytics that show the largest images and images you haven’t used for some time. On top of its tooling for working with WSL containers, WSL Container Desktop provides a basic settings tool that helps you configure its look and feel, as well as how it integrates with Windows.

Run Kubernetes inside Windows for cloud-native development

One of the more useful features of WSL Container Desktop is the ability to quickly stand up a K3s Kubernetes instance in WSL that can be used to host WSL containers, providing a local environment to build and test cloud-native applications wherever you might be. The K3s tooling offers a similar experience to the Kubernetes project’s own Headlamp UI, making it easy to go between your development environment and a production Kubernetes cluster.

It’s fair to describe WSL container as one of those Windows features you didn’t think you needed, but now it’s here you can’t live without it. WSL container simplifies building a container development tool chain in Windows, and at the same time allows you to think about a new generation of hybrid applications that take advantage of decades of development in both Windows and Linux.

The result is something that was unimaginable a few years ago: dropping a Linux container into the middle of a Windows application and treating it as another local service. As the WSL container platform evolves, you should expect to see more ways of bringing Linux and Windows together, using containers to deliver a hybrid platform that gives us the best of both worlds at long last.

Cisco has revealed a family of open-weight AI models called Antares that, it said, can help security teams isolate potentially vulnerable parts of a software repository before deeper investigation begins.

Rather than detecting a specific CVE or generating a patch, these models search a codebase using only a Common Weakness Enumeration (CWE) description and return the files most likely to contain that class of vulnerability.

“Its purpose is to reduce a large codebase to a focused set of files that a security professional or a downstream security workflow should investigate,” Cisco’s AI researcher Supriti Vijay said via email. “The goal is not to replace a security engineer’s judgement or send them on a wild-goose chase, but to reduce fatigue and workload by helping them triage an issue earlier and focus their investigation on the most relevant parts of the codebase.”

The Antares family consists of models with 350 million, 1 billion, and 3 billion parameters trained specifically for repository-scale vulnerability localization.

The company said its largest model approaches the performance of GPT-5.5 on its internal vulnerability localization (Vloc) benchmark while remaining small enough for low-cost local deployment.

A search assistant, not a vulnerability detector

Cisco is careful to define what Antares is, and what it is not.

“Antares outputs a ranked list of source files likely to contain a relevant vulnerability, along with the terminal exploration trace that led to that result,” Cisco Foundation AI Chief Scientist Amin Karbasi wrote in a blog post, adding that the models are not meant to replace the broader application security toolchain: Human analysts or downstream security tools will still be needed to confirm exploitability, identify vulnerable lines of code, assess severity and generate fixes.

Antares differs from conventional static analysis platforms such as Semgrep or CodeQL, which primarily rely on predefined rules or queries. Cisco instead describes Antares as an evidence-driven exploration agent that adapts its search as it traverses the repository.

Cisco’s argument is that large repositories often contain thousands of files, making manual reviews exhaustive and unrealistic. By reducing the search space to a manageable shortlist, the company hopes to reduce investigation fatigue without replacing human judgement.

Claims of specialization over scale

Cisco is also making a statement about how cybersecurity models should evolve.

Instead of pursuing larger foundational models, Cisco argued that specialized, task-trained models can outperform much larger open-weight alternatives for vulnerability localization. In its evaluation Antares-3B, the largest model intended for single-GPU deployments, produced results comparable to GPT-5.5 while outperforming several substantially larger open models by Google, OpenAI and Meta.

The family also includes Antares-350M for resource-constrained environments and Antares-1B for laptops and workstations, which Cisco has made available as open-weight models on Hugging Face.

The command line interface (CLI) on the models supports targeted CWE investigations, repository-wide scans, SARIF output and local inference, which Cisco said enables organizations to keep proprietary code inside their own trust boundary.

However, because Antares identifies candidate files rather than confirmed vulnerabilities, organizations will still need to understand how often such repository-wide searches should be run, how much they improve existing triage workflows, and whether the reduction in investigation effort ultimately translates into measurable security or cost benefits.

I use a very cool and relatively new web framework called Astro. The keen insight that the Astro team had was that most websites are made up of static content, so they made it really easy to add content to a website. To add a blog post to my personal website, all I have to do is create a Markdown file with some front matter, deploy it, and the blog post automatically appears. If I need to reach deeper for more dynamic functionality, I can easily do that with TypeScript, React, or almost any other framework. It’s really cool.

And these days, I really don’t write any code. Claude Code does most (all?) of the work. Since Astro is an open-source project and has excellent documentation, Claude knows all about how Astro works. It has no trouble at all managing my site and making the improvements I ask for.  

And that got me thinking, how does Astro get built? Is the Astro team building with agentic coding? Astro itself has many dependencies, including big projects like Vite and Node. And of course, Vite and Node have dependencies, too. Are those dependencies being developed by hand, or are those development teams also using AI agents to code?

My curiosity got the best of me, and I asked Claude to dig deeper. It turns out that the Astro repository has an AGENTS.md file, and some of the commits even have commit message trailers indicating that they were at least co-authored by Claude and GitHub Copilot. Further down, there is a .agents/skills directory with skills covering development, merging, triage, and more. I poked around for a look, and someone has done a great job building agentic support.

Now my interest is really piqued, and further investigation reveals quite a bit of interesting stuff. About a year ago, documentation started appearing about how to build Astro sites with coding agents.  Around that same time, the docs team released an MCP server that gives developers coding agents deeper, easier access to the Astro documentation.  

And there are small steps in the Astro codebase that indicate it is “agentic ready.” For instance, the command-line development server can tell when it is being started by an agent, and the application itself can tell if it is being driven by an agent. Small things, but steps in the direction of embracing Astro developers who use coding agents. 

Okay, that was a fun spelunking trip. But so what?

The “so what” is that code is going to be commoditized. As an Astro developer I am using AI agents pretty much all of the time. The Astro development team is starting to use AI agents more and more. The folks building the Astro dependencies are using AI agents. Shoot, the people building Claude Code and the agents themselves are “eating their own dogfood” and using their own tools to build the next frontier model. Before we know it, it will be turtles all the way down. 

No one says “who generated that electricity?” or “who wove the fabric in that shirt?” any more. And it won’t be long before no one says “Who wrote the code for that app?” because it won’t matter. Just as we don’t look at the assembly code written by our compilers, we’ll stop looking at the “regular” code written by our agents. I’m not even sure anyone is writing assembly code anymore. Soon we’ll be saying that about TypeScript, Python, and C++.

Microsoft has released Visual Studio Code 1.129, an update to its free, popular code editor that features a dedicated agent host and an editor panel in the Agents window. The updated editor also allows users to run terminal commands from chat prompts with a !prefix and offers a preview of a modern UI for the workbench.

Released July 15, VS Code 1.129 can be downloaded from code.visualstudio.com for Windows, Linux, and Mac.

Microsoft is rearchitecting how agent sessions work in VS Code around the agent host — a dedicated process that runs agent harnesses such as Claude, Copilot, and Codex, based on the Agent Host Protocol (AHP). Since a session lives in its own process, the same session can be connected to and rendered from multiple VS Code windows at once. The agent host’s Copilot agent is powered by the Copilot SDK, which means that its behavior and functionality is aligned with the Copilot CLI, the standalone GitHub Copilot app, and other Copilot products. The agent host is being rolled out to users in the editor window and the Agents window. It’s enabled through the chat.agentHost.enabled setting.

The Agents window shows conversation with an agent next to a detail area for the files and changes it produces. This release introduces a redesigned editor panel that brings the editor and the detail area together into one docked pane with a shared tab bar, so reviewing an agent’s work feels like working in the main editor instead of switching between separate panels.

Other new features and improvements in VS Code 1.129:

• Users now can prefix chat messages with a ! to run their contents as terminal commands. This works in agent host sessions, both in the editor and in the Agents window.
• Developers can now use Bring Your Own Key (BYOK) models in the Agents window when selecting the Copilot harness running on the agent host.
• Developers can preview a modernized VS Code UI that updates the look and feel of the editor workbench. This is currently an experimental feature that can be enabled with the workbench.experimental.modernUI setting.

VS Code 1.129 follows Visual Studio Code 1.128, released July 13. An update, VS Code 1.129.1, fixes three bugs including remote agent hosts failing to start.

Discover More Topics From NASA

Discover More Topics From NASA

OpenAI is selling its first hardware — without any help from Jony Ive. It describes the Codex Micro as a “command center for agentic work” but it’s really a 13-switch wireless keyboard customized to help developers keep tabs on what their Codex agents are doing. It costs $230.

The keyboard has 13 mechanical switches (one keycap covers two of them by default), a rotary encoder, joystick, and RGB backlighting around the whole keypad and individual keys. It comes with 32 customizable icon keycaps.

OpenAI claims that the Codex Micro is a serious business tool: The command keys enable Codex users accept changes, reject outputs, push-to-talk, start new chats, and trigger custom actions. The rotary encoder can be used to dial up the “brainpower” allocated to tasks — or in more conventional terms, how many tokens to allocate to reasoning on a task. And the RGB lighting can provide feedback on how various tasks are progressing. And the RGB lighting under the “agent” keys can provide feedback on how various tasks are progressing.

The Codex Micro’s manufacturer, Work Louder, already has a similar device on the market, the Creator Micro, which offers similar functionality, but without the colorful keys. It costs $56 less than the Codex Micro, however.

The Codex Micro will fit in snugly with OpenAI’s other merchandise, where using Codex is as much about a fashion statement as a technological choice.

Linus Torvalds has a complicated relationship with AI, seeing both its good and bad points. But his latest remarks on the usefulness of AI may have raised a few eyebrows in open-source circles.

Just a few weeks after the Linux founder complained that a “continued flood” of AI-generated vulnerability reports had made the Linux kernel security mailing list “almost entirely unmanageable”, he has come to see the advantages of the technology.

“Linux is not one of those anti-AI projects,” Torvalds wrote in an email response to Linux Kernel senior engineer Roman Gushchin, archived at Kernel.org.

“It can also be a somewhat painful tool, both for maintainer workloads and just from a ‘it keeps finding embarrassing bugs’ standpoint,” he said of the use of AI in security scanning. “The solution is to make sure those LLM tools help maintainers instead of just causing them pain.”

Developers should be free to choose whether they use AI, he said. “We’re not forcing anybody to use it, but I will very loudly ignore people who try to argue against other people from using it.”

Torvalds’ measured support for AI does not come completely out of the blue: Around the same time that he was complaining about AI distorting security maintenance, he also spoke about its usefulness, claiming that it could improve programmer productivity by a factor of 10.