Claude Dispatch’s desktop boundary, new model weights and Conductor’s exit

Claude Dispatch’s desktop boundary

A browser extension opened Calculator on a desktop through Claude Dispatch. The important part is the route it took: a logged-in web session could become a path to commands on another computer.

Our main story today is that Dispatch research, and how linking an AI assistant across devices changes who can set work running on your desktop. For organisations, the concrete concern is a browser extension reaching files and commands through an account that also connects to a work computer.

Forever Security disclosed the proof of concept on 4 November. The Register covered it on 5 November. The researchers started with an extension able to control Claude’s website, authenticated sessions in both the browser and desktop app, and Dispatch enabled. Those ingredients gave the extension a route into a feature designed to let someone assign work remotely.

In the demonstration, the extension automated approval clicks and caused a package to be installed that opened Calculator. Code ran on the desktop. Exploitation in the wild remains unconfirmed.

The approval clicks are the revealing detail. A button can look like a moment of human consent while still being something software can press. If the extension controls the page presenting that decision, the click alone gives the desktop very little information about who intended the action. The web session is authenticated, but the person behind the account may never have asked for that particular task.

Dispatch then supplies the connection between the browser request and desktop execution. Each part has an understandable purpose: a signed-in session identifies an account, an approval allows work to proceed, and a remote-task feature carries the request to a machine that can do it. The weakness appears in how those parts fit together. Authority can travel further than the person using the browser expects.

That becomes especially relevant across devices. The researchers describe the connection extending to another computer using the same Claude account. So the browser where an extension runs and the desktop where a command executes can be different machines. A personal browser and a work desktop could become connected through that shared account.

For an organisation assessing exposure, that gives the investigation a useful shape. Which browsers have extensions with access to Claude’s website? Which accounts connect those browsers to desktop sessions? And where is Dispatch enabled? Those details identify the route demonstrated here without treating every use of Claude as the same situation.

There’s also a product-status detail that affects existing users. Anthropic’s support page still allows them to continue using Dispatch in limited beta, while excluding new users. Reporting describes a retirement plan, but the timetable remains unresolved. Existing access is therefore the relevant starting point for anyone checking their own setup.

My takeaway is that genuine authorisation deserves its own scrutiny when an assistant can act across devices. Recognising an account answers who is signed in. It leaves a separate question about who requested a command, and whether the person at the receiving computer intended to allow it.

For buyers of these tools, the useful security question is very concrete: what stops software controlling one connected surface from approving work on another? The answer needs to survive the convenience of remote access. Otherwise, an extension permission that seems confined to a browser can carry consequences all the way to a desktop.

The UK’s proposed agent incident duties

That’s the desktop boundary; the shorter news starts with what happens when an organisation loses control of an agent.

The UK government updated its agentic AI resilience factsheet on 3 November, setting out measures it intends to introduce using powers proposed in the Cyber Security and Resilience Bill. The focus is regulated networks and information systems, including the kinds of infrastructure operated by essential-service, cloud and managed-service providers.

There are four parts: security controls, notification of affected organisations, preservation of incident evidence, and government-led technical reviews. In practical terms, the proposal looks beyond stopping an incident. It also asks how people affected by it learn what happened, and how the sequence can be reconstructed afterwards.

That reconstruction can be difficult with an agent. An initial request may lead to several actions, with later steps depending on earlier results. If something goes wrong partway through, the original instruction alone may explain very little. The useful record connects the request to the actions that followed and the systems they touched.

Preserving evidence and enabling a technical review would put that operational record under scrutiny. For a service operator buying agent software, access to usable activity records could become as relevant as the feature that made the product appealing in the first place. An incident is a poor time to discover that the explanation lives somewhere the operator can’t retrieve.

These AI-specific duties are proposed. Implementation would follow Royal Assent, consultation and parliamentary approval of secondary legislation. Detailed coverage, the definition of losing control and implementation dates are still unsettled. That gives UK operators a direction to assess, rather than a new compliance deadline to meet today.

The scope is also specific to regulated systems. This proposal doesn’t create an Australian obligation or cover every application that happens to include AI. For organisations operating in the relevant UK sectors, though, it makes the government’s intended response considerably more concrete.

I’d read the purchasing consequence this way: the ability to explain an agent’s actions is becoming part of operating it. Software that leaves an accessible trail could make incident response easier, particularly when the affected organisation and the company supplying the agent are different businesses.

Claude’s European processing timetable

There’s a separate workplace question for Claude users in Europe: where does the processing happen?

Microsoft announced on 5 November that Claude models used through Copilot will enter its EU Data Boundary by the end of 2026 for eligible organisations in the European Union and the European Free Trade Association. The commitment includes Copilot Cowork and covers regional processing as well as storage.

That distinction has a practical effect. Storage describes where information is kept. Processing describes where the work on that information happens. A business deciding whether it can put internal material through a model needs to understand both parts of the arrangement. A regional storage commitment answers only part of that question.

Microsoft says eligible existing users will move automatically when the change becomes available. That offers administrators a stated transition path without a separate manual migration for those users. There’s no exact availability date yet; the announced target is the end of 2026.

For now, Claude access remains disabled by default in the EU and EFTA. An administrator can enable access, but the promised regional processing migration is still ahead. The distinction matters for a company whose approval depends on processing location: availability of the model and availability within the promised boundary arrive on different timetables.

From a buyer’s perspective, this could remove a practical obstacle to using a model the organisation already wants. A developer might be satisfied with the answers, while the people responsible for business data are waiting on hosting arrangements. Microsoft is giving that second group a timeframe they can work with.

The announcement is specific to eligible European organisations. It doesn’t include an equivalent commitment to Australian processing, so Australian businesses won’t get an answer to their own regional hosting question from this change.

My reading is that model choice at work increasingly depends on these service details. The same underlying capability can become usable for a business once its processing arrangements fit that business’s needs. Here, the milestone to watch is the actual transition into the boundary, because that’s when the announced hosting change becomes part of the service people use.

Inkling 2 Small arrives on Tinker

For developers choosing a model to customise, there’s a new option available through a hosted service.

Thinking Machines launched Inkling 2 Small on 5 November, with inference and fine-tuning available through Tinker. Inference is running the model to get an answer; fine-tuning adjusts it through further training for the work you want it to do. Developers can begin both through the service now.

The company describes a mixture-of-experts model with 594 billion total parameters and 17 billion active. That architecture uses a selection of the model’s parameters for each step, rather than applying the entire set every time. The active count helps explain the work performed during generation; the total count describes the much larger model behind it.

It also supports image input and adjustable reasoning effort. That gives developers two useful dimensions to explore: whether a task needs visual information, and how much reasoning to allocate to an answer. A short, straightforward request and a more involved problem can place different demands on the same model.

The release is initially closed-weight. Thinking Machines intends to publish the full weights under Apache 2.0 in the following week, subject to completing external safety testing and red-teaming. Downloadable fine-tuned checkpoints depend on that weights release too.

So a developer can evaluate and customise Inkling on Tinker today. A project that needs to run the resulting model on its own infrastructure still has a dependency to wait for. That’s a meaningful distinction for someone deciding whether this fits a hosted experiment or a deployment they need to control themselves.

The proposed checkpoint downloads are particularly interesting. Fine-tuning represents work put into making a model useful for a particular purpose. Being able to take the resulting checkpoint elsewhere would give that work a life beyond the hosted service where the training happened.

For developers, I see the immediate value in having a concrete place to test that customisation. The portability question has a separate, observable answer: whether the promised weights and downloadable checkpoints arrive. A project can make progress on evaluation now while keeping its self-hosting schedule tied to that release.

ERNIE’s weights and licence

Baidu has already released a model’s weights, with a different starting point for anyone building on them.

ERNIE 5.5 Flash Base is available as a pre-training checkpoint, under a custom licence dated 5 November. It hasn’t undergone instruction training or other post-training. Developers get the base from which to build their own model behaviour, with that additional training work still ahead.

That makes the release most relevant to specialists who want control over how a model is adapted. A conversational assistant is trained to respond to instructions in a particular way. Starting from the base checkpoint gives a developer responsibility for shaping that behaviour, rather than beginning with an assistant whose post-training choices have already been made.

Baidu describes 280 billion total parameters, with 14 billion activated per token. As with other mixture-of-experts designs, only part of the model participates at each step. The full model still sets substantial infrastructure demands. Downloads are available in FP8 and BF16, two numerical formats using different precision to represent the weights.

The licence adds another set of choices. Its territory excludes the European Union, the United Kingdom and South Korea. Commercial use at or below 50 million US dollars in related annual revenue has no model licence charge, but requires notice and attribution. Above that threshold, prior written commercial authorisation is required.

Those conditions are relevant early in a project. A specialist developer might have the infrastructure and training expertise to make the checkpoint useful, yet still need to account for where the resulting system will be used and the commercial terms applying to that business.

It’s a release with a clear audience: people who can do their own post-training and want access to the underlying weights. For that group, the scope to shape the model may be valuable. The work includes training decisions, infrastructure and the licence conditions attached to deployment.

My takeaway is that technical control and commercial freedom are separate parts of the decision. Downloading the checkpoint gives developers something tangible to build on. The custom licence determines which markets and business arrangements that work can serve, so the intended deployment belongs in the model-selection conversation from the start.

AWS maps installed software

A smaller update from AWS could save security teams some searching when a vulnerable package turns up.

On 6 November, AWS added an organisation-wide software inventory to Security Hub, assembled from Amazon Inspector’s software bills of materials. An SBOM is a list of the software components in a system. Here, the inventory brings package names and versions together across supported resources.

Coverage includes supported EC2 instances, ECR container images and Lambda functions. The information is accessible through both the console and an API, so people can inspect it directly or use it in their own tooling. It populates where Inspector is enabled and is included with Security Hub Essentials at no additional charge.

The useful moment is when a vulnerability names a particular package version. A security analyst needs to find where that version is installed before deciding which systems need attention. An aggregated inventory can shorten that search across the covered AWS resources.

Its reach follows Inspector’s coverage, so systems outside that collection still need their own inventory. Within it, the benefit is fairly direct: less time locating affected software and more time deciding what to fix first. Remediation remains a separate step, but finding the right resources is a useful part of getting there.

Qualcomm’s near-memory milestone

Down at the hardware level, Qualcomm is working on the cost of moving data around during AI inference.

On 2 November, the company reported that its first-generation High Bandwidth Compute silicon had validated complete memory read-write paths and near-memory computation in laboratory hardware. The tests used randomised weights and activations at production-representative dimensions.

Near-memory computation puts processing closer to the data it uses. Moving model data consumes energy, so reducing that movement offers another way to work on inference efficiency. The interesting milestone here is having working silicon that exercises those memory paths and computation together.

Qualcomm expects Dragonfly AI250, which is intended to integrate the technology, to sample in the first half of 2027. For infrastructure buyers, that places it on a future evaluation timetable. The eventual efficiency advantage will depend on the workloads and implementation, with independent system-level performance and commercial pricing still ahead.

I’d watch how the approach performs once it’s integrated into the accelerator. Buyers pay for a system doing useful work, and moving computation closer to memory could change how much energy that work takes. This result advances the hardware towards that test; the sampling schedule gives us a concrete next milestone.

What Changes for You

If your coding work lives in Conductor Cloud, there are two dates worth separating in your calendar.

Conductor announced on 4 November that it was joining Meta and began winding down its cloud coding-agent service. New sign-ups and app downloads have closed. Existing Pro users can retain Pro features free, and active subscribers are promised refunds.

The first deadline is 13 November, when cloud workspaces become read-only. Old chats remain readable and exportable, but you can’t send new messages. That’s the end of interactive cloud work, even though there’s still time to retrieve material.

The second date is 20 November. Conductor Cloud shuts down then, and the company begins deleting cloud user data. Anyone using the service for an active project has a shorter window to keep working there than to recover what’s already stored.

Conductor provides workspace transfer to a local Mac and data export. That gives existing users a way to recover working material and continue locally where appropriate. The local application has its own support horizon: new models and critical bug fixes are promised only until early 2027.

For a developer, the immediate disruption may sit around the code as much as inside it. Chats can hold the explanation of why a change was made, what an agent already tried, and where a task was heading. Moving a repository leaves a separate job of preserving that useful working context. The available chat export makes that distinction especially relevant here.

There’s a promised replacement product, but no firm launch date or specified migration guarantees. Existing users have concrete recovery options through export and local transfer in the meantime.

The immediate priority is preserving a usable workspace and its chats while those recovery options are still available. That gives developers more choice about where to continue the project.