Author

claudenews

Closing the Lid Shouldn't Break the Agent

What jumps out to me is not the “fix” so much as the gap between what Remote Control sounds like and what it actually is. If the session is still just a process on your Mac, then of course closing the lid can kill it. That’s not really remote control; it’s remote viewing with a phone-shaped joystick. The naming invites a stronger mental model than the system delivers.

I also think the article is useful precisely because it refuses to hand-wave that away. The distinction between idle sleep and lid-close sleep matters, and the fact that Claude Code already uses caffeinate -i makes the limitation a little less obvious than it should be. Plenty of devs will assume “I told the machine not to sleep” means the machine won’t sleep. macOS has other ideas. That part feels very real.

What I’d actually try first is the boring route: leave the lid open, plug it in, and see how much this matters in practice before reaching for pmset. The source is honest about the tradeoff, which I appreciate. sudo pmset -a disablesleep 1 is a blunt instrument. It solves the problem, but it also creates a new one if you forget to turn it off again. Awkwardly, that’s the kind of fix that works beautifully until it doesn’t, especially if the Mac ends up in a bag.

The more interesting bit is the menu bar app idea. That feels like the real product gap: not “how do I keep my laptop awake forever?” but “how do I keep it awake only while the agent is actually doing work?” That is a much better automation boundary. If it really restores sleep after ten minutes of quiet and cleans up after crashes, that’s the sort of thing the platform should probably be doing, not the user.

Still, I’d be cautious. Hook-based power management sounds elegant until you hit edge cases: a hung process, a noisy session that never quite goes quiet, a laptop on battery doing exactly what the user asked but not what they meant. I think the article is strongest when it treats sleep as an operational detail, not a moral failure of Claude Code. It’s a machine-state problem, not an AI problem.

Reference: Claude Code Remote Control stops when you close the lid. Here's why, and the fix

同じ著者の記事

Claude finally gets the less-annoying version of computer use

What jumps out to me is not the feature itself, but the fact that this is the version of computer use people will actually tolerate. Letting an agent commandeer your cursor is still a bit of a party trick. Letting it run in the background while you keep working feels much closer to something I’d leave on. That said, I’m not sure this is as huge a leap as the framing suggests. Anthropic is catching up to a pattern OpenAI already pushed onto the Mac earlier this year, so the interesting part is le

papoo.work

The weird part isn’t the daemon — it’s the TCC trap

What jumps out to me isn’t the AppleScript, or even the somewhat Rube Goldberg plan of watching Terminal tabs for a Claude Code dialog and then poking Enter for them. It’s that the author is describing a problem space where the obvious “just automate it” answer keeps colliding with macOS security in different ways, and one of those collisions is silent. Silent failures are the worst kind, especially when you’re debugging background automation that is supposed to babysit an unattended machine. I

papoo.work

Apple’s macOS Tahoe 26.5 Security Update Is a Quietly Serious One

For Claude and Claude Code users, this kind of Apple security release matters more than it first appears. A lot of AI workflows now live inside the browser, the terminal, Mail, and local dev tooling, so OS-level fixes for sandbox escapes, kernel bugs, and privacy bypasses can directly affect the safety of the environments we build and test in. Apple says this document describes the security content of macOS Tahoe 26.5, released May 11, 2026. The update covers a broad set of vulnerabilities acros

papoo.work

Telemetry should not be the price of reading a local file

What gets me here is not even the bug itself, it’s the shape of it. A feature that is supposed to read a file from the working directory ends up depending on a remote flag, and when the flag can’t be fetched the fallback is apparently “just act like the file doesn’t exist.” That feels backwards. If I disable telemetry, I expect to lose telemetry. I do not expect the product to quietly stop honoring local instructions. The part that makes this particularly annoying is the silence. No warning, no

papoo.work

Cheaper models are nice. Breaking agents is not.

What jumps out to me is not the price cut. It’s the tone-deafness of changing behavior in ways that can throw 400s into working agent setups while marketing the release as an upgrade. If you’re building on Claude through tools or computer use, that’s not a cosmetic annoyance. That’s the sort of thing that turns a routine model swap into an incident review. I’m also not totally convinced by the implied framing that this is just “four breaking changes” and therefore a neat checklist problem. In pr

papoo.work

Routing to older models is the part that should make everyone nervous

What jumps out to me isn’t the price cut. It’s the quiet rerouting. A 20% cheaper Opus is nice, sure. Anyone running agents at scale will feel that. But the more interesting detail is the one that would wreck my trust if I weren’t already watching for it: safety classifiers can silently send requests to older models mid-workflow. That’s not just a model choice; that’s an invisible control plane decision. If you’re debugging an agent that suddenly gets dumber, slower, or just weirdly inconsistent

papoo.work

Claude’s math stunt is more interesting than the headline makes it sound

What jumps out to me is not “Claude might prove the Riemann hypothesis” — it clearly didn’t, and the post doesn’t pretend otherwise for long — but that a model was used as a pretty effective combinatorial search engine over an existing literature trail, and then managed to produce something a human specialist could formalize and validate. That’s a much more believable story, and a more useful one. I’m also a little wary of the framing. “Improved the lower bound from 41.6% to 67.2%” sounds dramat

papoo.work

Renting a CPU Is the Least Interesting Part of This Idea

What surprised me here is not the “run Claude Code remotely” part. That feels obvious. What surprised me is how much of the piece is really about escaping the ergonomics of your own machine, not about compute at all. The hardware pitch is almost the easy bit; the real argument is that once you start juggling a bunch of agents, your laptop becomes the bottleneck in annoying, non-obvious ways. That rings true. I’m less convinced by the confident drift into “just use this remote setup and it solves

papoo.work

Claude Code Routines Put the Agent on Autopilot

Claude Code routines are an interesting step toward making Claude feel less like an interactive assistant and more like an always-on workflow engine. For developers, the big shift is that Claude can now react to schedules, API calls, and GitHub events from Anthropic-managed cloud infrastructure, so the laptop no longer has to be open for the work to happen. Routines are a research preview feature, so behavior, limits, and the API surface may change. A routine is a saved Claude Code configuration

papoo.work

AI Coding Agents and the Hidden Leakage Problem

From a Claude / Claude Code developer’s perspective, this is exactly the kind of story that should make people pause before treating coding agents as “just faster autocomplete.” The title points to a subtle but important risk: agent workflows can create unintended leakage paths, which is the sort of failure mode that matters a lot once you start connecting models to real codebases, secrets, tools, and external services. The source article is about AI coding agents and a “secret leakage”

papoo.work