Five Releases in One Day: The Engine Is Foxl Code Itself

On July 22, 2026, Foxl shipped five production releases in one day: v0.4.15 through v0.4.19. Each one went everywhere - six web surfaces, a signed and notarized macOS build, and an iOS TestFlight build. This post describes the process that made that pace ordinary, which is also the product: Foxl Code doing the work on the Foxl repository itself.

What actually shipped

The five releases carried product changes rather than version bumps, including one production incident found and fixed within the hour:

• v0.4.15 restored the Skills, Channels, and custom MCP tabs that a Settings refactor had orphaned, and fixed a group of mobile cold-start bugs that all came from one iOS lifecycle fact.
• v0.4.16 was a critical hotfix: a relay-internal field was leaking upstream and every model returned an empty reply on mobile whenever the desktop was offline. It was diagnosed against a local relay, fixed at the root, regression-tested against the real provider, and released the same day it was reported.
• v0.4.17 made every failed turn answer back with an explanation inside the conversation, fixed Stop on mobile, and opened GPT-5.6 Luna to the free tier.
• v0.4.18 reworked the mobile header, turned the phone terminal into a full-screen page, and shipped an experiment: real native Liquid Glass on iOS via a new Capacitor plugin.
• v0.4.19 reverted that experiment, which failed on real devices for the reason described below, and finished the terminal work with a reconnect control and a duplicate-tab race fix.

The loop that makes five releases normal

Every one of those releases followed the same loop, with Foxl Code working in the Foxl monorepo. A person describes what they want - often as tersely as a screenshot and one sentence of annoyance. The agent reads the code, finds the root cause, writes the fix, runs the typecheckers and both build variants, deploys the staging or production surface it can safely deploy, and writes the changelog entry in the same commit. The person stays involved the whole time, as the editor who decides what is right, but does not type the code.

The releases themselves are one command each. A release script bumps nine package manifests together, deploys the relay, the orchestrator, three web apps, the docs, and the marketing site, builds and notarizes the desktop app, and uploads it through a release bot. A second script builds and uploads the iOS app. The agent runs both, watches them, and handles the aftermath - committing the version bumps, moving the git tag to the right commit, verifying every surface responds, and checking that no source maps leaked into the binary. When the release script died halfway through v0.4.17 because of a stray environment variable, the agent finished the remaining surfaces by hand, in order, and then wrote the failure into its own operating notes so the next release would not repeat it.

Speed is a memory problem, not a typing problem

Most of the pace comes from accumulated context. The agent keeps a persistent memory of the project: which install flags break the monorepo, which release script leaves the tag on the wrong commit, which test suite once exhausted the machine's ports and must never auto-spawn its server. With five releases in a day, none of that knowledge has to be rediscovered: the second release of the day inherits everything the first one learned, and release five runs cleaner than release one.

The same memory is why bug reports written in one line still land as root-cause fixes. "Stop does nothing on my phone" became a two-layer diagnosis - an abort signal dropped by a fetch interceptor, plus iOS swallowing the tap during keyboard dismissal - because the agent already had the app's tunnel architecture in its memory and could trace the signal path instead of guessing.

Shipping a mistake and unshipping it, same day

One of the day's changes was an experiment that failed. v0.4.18 shipped real native Liquid Glass on iOS - actual system glass views tracked behind the web content, built as a new Capacitor plugin in a few hours by porting the architecture of a macOS Electron library. It compiled, it ran in the simulator, and on a real device it was wrong: black bands at the top and bottom, and no glass at all.

The cause was the platform architecture rather than a bug in the plugin. The macOS approach works because a Mac window can be transparent - glass behind the web content samples the desktop behind the window. An iPhone app is fullscreen; behind its web view there is only the app's own black container, so the glass had nothing to sample, and making the web view transparent just exposed the black. v0.4.19 reverted it the same day, kept the plugin repository as a reference, and recorded the analysis in the project's memory so the idea does not get re-attempted in the same shape. Being able to revert on the same day, with the reason written down, mattered as much as being able to ship.

What the human does all day

None of this ran unattended. The day was a continuous conversation between the agent and a person. The human sent screenshots of a cramped terminal UI and said "this is terrible, make it slide in from the right." They caught the header peeking above the terminal and said cover it. They tested glass on a real device and said revert it. The decisions in every release were theirs, and none of the code was typed by them. Foxl Code is built around that split between human judgment, agent execution and a shared memory, and July 22 was a good day for it.

The numbers

• 5 releases: v0.4.15, v0.4.16, v0.4.17, v0.4.18, v0.4.19
• Each release: 6 web surfaces deployed, a notarized macOS build, an iOS TestFlight build (builds 1426 through 1453)
• 1 production incident root-fixed with a live regression test, same day it was reported
• 1 experiment shipped, disproven on hardware, and reverted
• 1 new open-ended capability for free users (GPT-5.6 Luna), 1 new plugin repository, 2 blog posts - including this one, which Foxl Code also wrote

Foxl Code runs the same loop on your own repository: you describe the change and review the diff, and the agent writes the code.