Day 127: v0.7.0 — Skills, One Clicks, and Sessions That Survive an Update
v0.7.0 is out. Three things landed together, and they look unrelated until you notice they all answer the same question: how does a self-hosted agent platform get more capable without getting less governable. That tension is the whole job here, so it’s worth taking each one on its own terms.
A skills foundation, web search as the pilot
The headline is a skills framework. Let me be precise about what that means, because “skills framework” is the kind of phrase that invites you to imagine a catalogue, and there isn’t one yet. What shipped is a foundation plus one real skill.
The instinct, faced with “agents should be able to do more things,” is to build a capability system. I didn’t, because OpenClaw 2026.6.x already has one: native skill mechanics, a SKILL.md per skill, a six-tier loading precedence, and a per-agent allowlist. This is the same line I keep drawing — the runtime is someone else’s house, so I don’t rebuild a room it already has. Pinchy adopts the native mechanism and adds the one thing it’s missing for enterprise use: governance over which skills an agent gets.
The governance part is a single design decision, and it’s the part I’m happiest with. OpenClaw ships 58 desktop skills out of the box — 1Password, Apple Notes, all the things that make sense on a developer’s laptop and make no sense on a shared agent inside a company. Pinchy emits an explicit skills allowlist for every agent, always, even when it’s empty. An empty allowlist means none of those 58 load. So the default is not “the agent has whatever the runtime bundled.” The default is nothing, and an admin grants a skill the same way they grant a tool. Default-deny at the skill layer, the same shape as agent permissions.
The first skill in that allowlist is web search. An agent with the web-search skill can research the live web — search and fetch — and the skill itself carries the workflow guidelines: ground claims in sources, prefer recent results, don’t fabricate. It’s the obvious first skill because it’s the one customers keep asking for, and because it’s the one with the sharpest governance story. ChatGPT can search too, but there your prompts leave the company. With Pinchy the search runs from your own instance, and every query is in the audit trail. That contrast is worth its own page, so web search got a dedicated one.
To make it concrete, v0.7.0 also ships a template that uses the skill: Market & News Monitor. It’s a research agent — point it at competitors and a market, and it watches the live web instead of going stale the moment you stop feeding it documents. One agent, one job, scoped to a group. That’s the shape I want every team to reach for: a research agent here, a support drafter there, each granted exactly what it needs.
Two one-click deploys
The second thing in v0.7.0 is about getting started. Self-hosting is the point of Pinchy, but “self-hosted” shouldn’t mean “spend an afternoon wiring up a compose stack before you can see the thing run.” So there are now two one-click paths.
The DigitalOcean Marketplace image is a Packer build that snapshots Pinchy’s real production stack — Pinchy, OpenClaw, Postgres — with no security-model adaptation for the demo. It’s the same thing you’d run for real. The shared snapshot carries no secrets; a per-Droplet first-boot script generates them, so two people who deploy the image don’t share a key. The CapRover path is a one-click app template for people who already run a CapRover box. Both pin to the exact release, so a one-click deploy gives you a known-good version, not whatever happened to be latest.
Neither of these changes what Pinchy is. They change how long it takes to get a running instance from “I read the homepage” to “I’m talking to Smithers.” For a product whose whole pitch is “run it yourself,” that first five minutes matters more than I used to think.
Your session now survives an update
The third one is the quiet fix, and it’s the one I’d have been most embarrassed to leave in. On every HTTPS, domain-locked instance, every update was silently logging everyone out. Annoying on its own. Worse as a signal: an enterprise buyer who watches their whole team get kicked out the first time they patch is going to wonder what else a patch breaks.
The cause was subtle and I’ll write it down because it’s a good trap. Better Auth derives the session cookie’s name from whether Secure cookies are on — the __Secure- prefix. Pinchy read that flag from an in-memory domain cache that is cold at module import and not deterministic across container generations. So across two deploys the flag could resolve differently, the cookie name flipped, and the browser’s existing cookie was suddenly the wrong name. Orphaned. Logged out. The fix keeps the documented model — a locked domain is the source of truth for Secure mode — but makes the decision synchronous and stable: the locked domain is mirrored to a flag file in the persistent secrets volume, read synchronously at boot, so the cookie name is the same on every restart. One last re-login when you upgrade onto the fix, then it stays put.
It’s the least glamorous item in the release and arguably the most important. A capability you can’t trust to survive a routine update is not a capability a company will lean on.
Day 127
Three features, one theme, again. The skills allowlist is governance wearing a capability hat. The one-click images are the same trustworthy production stack, just easier to start. The cookie fix is making “stay logged in” a promise that holds across the thing you’ll do most often, which is update. More capable, still governable. That’s the only version of “more” I’m interested in shipping.