A work in progress

Quick Notes

Development Log

PickleShell started with a simple idea: give ChatGPT a safe way to work with a real local machine instead of stopping at advice. The first version was still a small personal experiment, but the direction was clear.

The idea became a repository. PickleShell's secure monorepo appeared with the Gateway, MCP server, deployment documentation, security boundaries, and the first working bridge between ChatGPT and a local agent.

The first public release, v0.1.0, made long-running work practical. A request could return immediately, report progress through polling, be cancelled safely, and later provide its complete result instead of making ChatGPT wait on one fragile connection.

Reliability became part of the product rather than an afterthought. Explicit idempotency, structured metadata, session locking, safe file transfer, 209 concurrency tests, and 40 file-transfer tests gave the first release a much stronger foundation.

PickleShell got its public home on the web. The site began as a small explanation of the idea: ChatGPT can reason about a task, while PickleShell helps carry that task into a controlled local workspace.

The project grew beyond a single-machine story. The multi-machine use case made the larger ambition visible: one ChatGPT session coordinating different capabilities and destinations while each workstation remains locally controlled.

A new workstation connection changed the shape of the project. PickleShell was no longer just a local bridge on one computer; it was becoming a way to name, reach, and coordinate multiple workstations.

The Browser arrived with v0.1.1. Playwright gave PickleShell a new sense: the assistant could not only inspect code and run agent tasks, but also interact with the web and verify browser-facing behavior.

The idea proved itself far away from a desk. Sitting in a car with only a mobile phone, the operator used ChatGPT and PickleShell to guide agents through two difficult server fixes. The human stayed in control without becoming a manual relay, exactly the problem PickleShell was created to solve.

PickleShell learned to speak to Codex natively. The new adapter kept the same MCP contract while making the underlying agent replaceable, so the bridge could evolve without forcing the public interface to change.

The Terminal became a real interactive capability rather than a one-shot command runner. Persistent PTYs, reconnect behavior, lifecycle handling, signals, resizing, and isolation brought PickleShell closer to a complete workstation.

A clean installation on a fresh workstation passed the full system gate: Gateway, Terminal, tunnel, PTY reconnect, cgroup behavior, and Chromium E2E. The architecture had now been tested as one reproducible system rather than as a collection of successful components.

The project paused to clean its foundations. Vulnerable MCP dependencies were updated, all dependency audits returned zero reported vulnerabilities, and security maintenance became part of the normal development rhythm.