The review sounded ready. On September 16, in UTC, oobabooga, a contributor to unslothai/unsloth, reported testing Studio’s Python and terminal tools on Linux and macOS: files survived refreshes, downloads worked, cancellation left conversations usable, and the recorded launches used operating-system isolation. Less than a day later, the same public contributor authored the commit reverting that implementation.
For people letting a local model run code, that reversal matters more than a successful review sitting in a closed pull request. The source now takes a different route when it starts those tools. But reading the deletion as the removal of every protection would miss the most important distinction in the remaining code: an owner’s tool call and a managed account’s tool call do not receive the same confinement.
The boundary that landed, then left
The merged change inserted an OS-sandbox planning step around Python and terminal launches. On supported Linux hosts it used bubblewrap; on macOS, Seatbelt. The purpose was to change what the launched process could see and reach, rather than rely only on examining the code or command before running it.
That difference is concrete. A program can begin in a conversation’s working folder without being prevented from reading elsewhere. A filesystem boundary constrains the process after launch. A command check decides whether a proposed command may start. Both can be useful, but they answer different questions.
The new layer also accommodated hosts that could not provide isolation. Its automatic mode could keep the existing software safeguards; a required mode could refuse an unisolated launch. This was never a promise that every computer running Studio had acquired the same operating-system boundary. The review also said the effective execution mode was recorded in backend logs, not exposed in the ordinary interface.
The September 17 revert removes that planner, its platform backends and its launch wiring. In the inspected Python executor, the path returns to constructing a subprocess with the working directory, an environment selected for the execution mode, and the existing pre-execution setup. The terminal path follows the same pattern. The new tool_execution_mode argument is removed.
What the deletion does not delete
Studio still checks Python code before ordinary execution and still applies command checks on its terminal path. The executor retains environment handling, credential-path guards, resource limits where supported, and cancellation and timeout machinery. These are meaningful safeguards. They are not evidence that the reverted OS-isolation layer remains active.
There is another branch worth reading before making a blanket claim. Both executors still call _account_confinement() and apply its result before starting the process. In the separate account-confinement module, an owner context returns no account confinement. A managed account can receive a Linux Landlock or macOS sandbox-exec boundary. If that boundary is unavailable, the code refuses execution unless an owner-controlled option permits unconfined tools.
The practical consequence is therefore concentrated: the general isolation layer added for tool launches has been withdrawn, while the separately implemented managed-account boundary survives. A successful test under one account or on one host cannot settle the behavior of another.
A review is evidence about a particular version
The public review is useful evidence of the workflows its author exercised. It is not a guarantee that a later source tree preserves them. Nor does the revert establish that those tests were false. Its commit message names the reversal without explaining why it was made; the inspected record does not support assigning a motive or declaring an incident.
We traced the reverted and remaining launch paths, but did not reproduce kernel confinement or establish which installed releases contain either version. Operators evaluating Studio should identify their build and account mode before relying on the earlier review. A disposable test with harmless canary files can then ask the relevant question: what can this particular tool process actually read?
The next consequential signal is a replacement boundary—or a clear explanation of the intended owner-mode boundary—backed by tests that distinguish active isolation from software-only fallback. Until then, the receipt to follow is the process launch, not the reassuring conclusion at the end of yesterday’s review.