On Wednesday in Minneapolis, a federal agent fatally shot a motorist, 37-year-old Renee Nicole Good. Trump administration officials said these were “defensive shots” fired because the officer was being run over. But our analysis of bystander footage, filmed from different angles, appears to show the agent was not in the path of the victim’s SUV when he fired three shots at close range. Here’s how events unfolded. Moments before the shooting, the victim’s maroon SUV is stopped in the middle of the street. Multiple unmarked federal vehicles are idling nearby. Secretary Noem alleged the motorist “was blocking the officers in.” Bystanders are blowing whistles and yelling at federal agents. Then, federal vehicles start moving toward the maroon SUV with sirens and lights blaring. A federal agent films the scene on his phone. The driver rolls forward slightly, turning left, then stops and waves for others to go ahead. Two agents exit this silver pickup and walk toward the vehicle. Moments later, shots are fired. Let’s look at the scene again more closely. This is the agent who shoots the driver. He walks around the car filming and disappears from view. Other agents pull up and order the driver to exit her vehicle. One of them grabs at the door handle and reaches inside. The SUV reverses, then turns right, apparently attempting to leave. At the same time, the agent filming crosses toward the left of the vehicle and grabs his gun. He opens fire on the motorist and continues shooting as she drives past. The moment the agent fires, he is standing here to the left of the SUV and the wheels are pointing to the right away from the agent. This appears to conflict with allegations that the SUV was ramming or about to ram the officer. President Trump and others said the federal agent was hit by the SUV, often pointing to another video filmed from a different angle. And it’s true that at this moment, in this grainy, low-resolution footage, it does look like the agent is being struck by the SUV. But when we synchronize it with the first clip, we can see the agent is not being run over. In fact, his feet are positioned away from the SUV. The SUV crashes into a white car parked down the road. A bystander runs toward the collision. The federal agents on scene do not appear to rush to provide emergency medical care. Eventually, the agent who shot the motorist approaches the vehicle. Seconds later, he turns back around and tells his colleagues to call 911. Agents blocked several bystanders who attempt to provide medical care, including one who identifies himself as a physician. At the same time, several agents, including the agent who opened fire, get in their vehicles and drive off, apparently altering the active crime scene.
>Secure node state storage can help protect against a malicious actor copying node state from one device to another, effectively cloning the node. By using platform-specific capabilities, Tailscale ensures node state encrypts at rest, making theft from disk and node cloning more difficult.
>What we really care about here are those private keys stored in the state file, since those are used to identify your node to the coordination server and to other nodes. We need to protect them from exfiltration.
>If the Tailscale state file is unencrypted, an attacker with that kind of root access could use the file’s contents from a different machine and impersonate your node. From the perspective of the Tailscale coordination server, it’s as if your device switched to a different network and got a new IP address. We call this attack “node cloning”.
Not even that. An attacker with local root can just extract the wireguard keys from process memory, or use the TPM to decrypt the state file like Tailscale would.
The only scenario where it helps is a local attacker who can read the state file on disk, but is not full root. Kinda unlikely on Linux, but could happen on Windows.
Historical blog post from tailscale (August 2025) saying how awesome and important this feature was[1].
TL;DR If you care about the stuff mentioned in that blog post (which most sensible sysadmins would) then the implication is that you are no longer protected against those threat scenarios UNLESS you manually apply the flag at install time.
Which means for people using deployment scripts/tools you now need to update those to put the flag in during installation. Because previously you could rely on the feature being "on by default", which is no longer the case.
Essentially you run a server on some machine. Sessions are created in Docker containers, K8s pods, or via Zellij (an app similar to tmux).
You can:
- Directly attach to sessions via Docker attach (built-in via a TUI). You get a normal Claude Code experience, but multiplexed. The switcher/UI shows you the status of Claude and the PR (pushed, merge conflicts, CI status, review status, etc.)
- Manage sessions via a web UI. Connect to Claude Code directly via your browser. You have access to the usual Claude Code terminal or a native chat view.
- Manage sessions via an app. You have access to a native chat view.
It achieves isolation via Git worktrees + a proxy so that containers have access to zero credentials (there aren't even any Claude code creds in the container), which allows you to more safely use bypass all permissions mode.
This works better for me that Claude Code on Web because I have control over the environment Claude is running in. I can give it any Docker image I want, I can have it connect to my local network, etc.
It's still a WIP (the core bits are there, but it's not polished yet), but I'm hoping it provides a friendlier UX with a similar goal for what the OP has in mind.
Essentially you run a server on some machine. Sessions are created in Docker containers, K8s pods, or via Zellij (an app similar to tmux). You can:
- Directly attach to sessions via Docker attach (built-in via a TUI). You get a normal Claude Code experience, but multiplexed. The switcher/UI shows you the status of Claude and the PR (pushed, merge conflicts, CI status, review status, etc.)
- Manage sessions via a web UI. Connect to Claude Code directly via your browser. You have access to the usual Claude Code terminal or a native chat view.
- Manage sessions via an app. You have access to a native chat view.
It achieves isolation via Git worktrees + a proxy so that containers have access to zero credentials (there aren't even any Claude code creds in the container), which allows you to more safely use bypass all permissions mode.
This works better for me that Claude Code on Web because I have control over the environment Claude is running in. I can give it any Docker image I want, I can have it connect to my local network, etc.
It's still a WIP (the core bits are there, but it's not polished yet), but I'm hoping it provides a friendlier UX with a similar goal for what the OP has in mind.
reply