Building Pinchy in Public

Four days after 0.9.0, a bugfix release that exists because of one finding: on an instance that had locked its domain — the hardening we tell people to do — Pinchy's own plugins were being turned away by Pinchy's own security check.

Our release checklist used to say the candidate had been clicked through on staging.

A patch release is cut from the release branch, not from main, and on the day I started assembling 0.9.1 main was already 424 commits past the 0.9.0 tag.

The day after a release is for the website, and the website was showing product screenshots from June 18th.

Three weeks after 0.8.0, the release that gives agents your documents.

Pinchy's 'Test connection' button for a mailbox connected to any host and port an admin typed, and reported precisely why the attempt failed: refused, timed out, TLS error, credentials rejected.

Every local install of Pinchy told its owner 'Your Pinchy instance is not secured.

A production agent looked stuck: one model turn took 543 seconds and the audit trail said nothing.

No pull requests merged, no commits, no work at all.

Two things stopped being hardcoded today, and they had the same shape.

Agents could read data from Odoo, from a mailbox, from the knowledge base, and then had no way to give you any of it as a file.

Release-testing the IMAP connection end to end on staging, I opened the audit row for a sent email and found the recipient address and the complete message body sitting in it verbatim.

A customer upgraded their self-hosted box the way people actually upgrade: pull the new images, keep the compose file you already have.

The reliability index could tell you which models stay honest when a tool fails, but not what a task costs to attempt, which is half of any real decision.

Connect a mailbox to Pinchy on a cloud server and the test could fail with a bare 'Connection timed out,' which reads as 'your mailbox settings are wrong.'

A week ago I shipped GDPR pseudonymization for the audit trail: every row references a per-user pseudonym, so deleting a user makes their history unlinkable.

During staging verification for the next release, Pinchy started crash-looping about five seconds after it said 'ready.'

Yesterday the reliability benchmark's grader was the thing under scrutiny.

Agents couldn't remember things across sessions, so a rule someone taught an agent (which account certain invoices post to) got applied wrong the next day.

Pinchy publishes a reliability index that grades open-weight models on one thing: when a tool fails, do they report the failure or fabricate success?

A bookkeeping agent was sent a PDF ticket and spent two turns insisting the file 'seems not yet fully available in the workspace.'

The first durable piece of the Inbox Agent landed: the ledger that tracks which emails a workflow has already handled (PR #710), built on the background-jobs foundation from the org-timezone slice (PR #707).

Share to Pinchy lets you send a photo, PDF, or link from any Android app straight into an agent chat (PR #708).

Send a receipt to an agent over Telegram and something strange happened: the model could see the image, but no tool could open it.

The audit log now verifies its own hash chain in the background and can crypto-shred a deleted user without breaking the trail (PR #691).

Yesterday's fix broke up a fight between two Pinchy copies after it started.

Telegram lets exactly one process poll a bot token at a time.

Pinchy's balanced default on the Ollama-Cloud stack moved off glm-4.7 to kimi-k2.6 (PR #672, #671), and the reason is a specific, unglamorous incompatibility: glm-4.7 is reasoning-by-default and gets stuck in the reasoning_content round-trip that the /v1…

An admin re-set-up the Microsoft OAuth app, logged in, and got the app config but no integration.

Pinchy's email support was Gmail-shaped down to the bone, raw label strings and raw Gmail query syntax leaking straight into the agent's world.

The shape I keep coming back to for a normal company isn't one all-knowing assistant, it's one agent per job: a bookkeeper that lives in the accounting system, a mailbox agent that drafts replies, a support agent that knows the docs.

This week's zombie-server incident sharpened a question that self-hosting forces and SaaS lets you dodge: when the software breaks on a customer's own hardware, how does anyone fix it without me in the room?

A staging container reported perfect health while being completely broken.

A user sends an image to a text-only agent, tabs away, comes back minutes later, and their own message is gone from the thread while the agent's reply remains.

A bookkeeping agent on production spent about two hours failing to post a simple opening balance, trying roughly thirty ways to name the accounting journal and getting rejected on every one.

Before I cut v0.8.0 I run the same unglamorous ritual: click through the whole app on a staging instance with synthetic data, like a confused first-time user, and write down everything that feels wrong.

A quiet Sunday to say the strategic thing out loud.

The single most requested capability I haven't shipped is a real browser: agents that can read JavaScript single-page apps and pages behind an anti-bot challenge, which Pinchy's static fetch can't touch.

Reviewing an unrelated web fix, I found that Pinchy's per-agent tool gating was a deny-list, and a deny-list is only as complete as your memory of everything you have to deny.

Production PDF reads on the Ollama-Cloud-only stack started failing, and the audit log named the cause exactly: the vision model Pinchy had pinned was retired by Ollama Cloud on 2026-06-16, so every image and PDF read 410'd until the next upgrade and rest…

v0.7.0 ships three things that all answer the same question: how does a self-hosted agent platform get more capable without getting less governable.

The OpenClaw runtime image was shipping its own build toolchain to production: a C compiler, Python, and a 300 MB npm download cache, none of which the gateway uses once it is running.

On Day 120 the chat said the agent didn't respond when it actually had.

For months I had careful FAQ answers on 62 marketing pages, and 59 of them showed the answers to nobody: they lived only as FAQPage JSON-LD in the head, fed to a Google rich result and invisible to humans.

People ask what Pinchy runs on once you take it fully off the network, and the honest answer is that I have never touched the class of machine they mean.

Prepping an OpenClaw runtime bump, a Telegram test started failing deterministically: the read-only mirror read OpenClaw's session-scoped chat history, which a /new reset empties, so after a reset the web mirror went blank while Telegram itself still show…

A slash command typed in Telegram could erase the web chat history with the same agent.

On production, the chat kept saying 'The agent didn't respond' while the agent had in fact responded: a refresh revealed the saved reply, and anyone who didn't refresh never saw the answer.

I point the same scrutiny at the marketing that I point at the code, and it does not come out clean: a site-wide audit, cross-checked against the shipped product, finds 56 claims that don't match what Pinchy actually does.

v0.5.8 shipped today: lossless per-turn token accounting, PDFs rerouted away from OpenClaw's broken built-in tool, a model-blocklist gate, and a ten-advisory security sweep.