An app store that adapts to you
Möbius grew an app store. Install an app by pasting a URL, tweak it by asking, run it offline, save it to your home screen. The interesting part is not the store but that the agent does not build isolated apps, it grows a cross-app personal system that adapts to you over time.
TL;DR. Möbius grew an app store, and the store is the on-ramp. The real point is that the agent does not build isolated apps, it grows a cross-app personal system that adapts to you. Apps share a storage layer and a permission model, so the agent can compose them and reshape the whole thing around you over time. You install by pasting a URL, tweak by asking, run offline, save to your home screen, and break things cheaply because the system is built around recovery.
- The store is a curated starter pack, not a registry. A Möbius app is a public repo with a
mobius.jsonand anindex.jsxentry point. Sharing one means sharing a URL. - The bigger idea is a system, not a pile of apps. Shared storage and a shared permission model let the agent compose your apps and grow them around you.
- Updates are URL-keyed. Bump the version upstream, the store shows "Update available", reinstalling patches the code and keeps your data.
- Recovery makes breaking cheap. Atomic installs that cannot half-land, a
/recoverroute, and a git history of your whole instance. - Offline plus home screen. Apps install to your home screen as standalone PWAs and keep working with no network. Writes queue and sync when you reconnect.
- The honest edges. The full cross-app compose flow and per-app rollback are not built yet, and I say so where it matters.
This is the third post about Möbius, a personalized AI agent you self-host. The first post is about the agent building the tools you ask for and editing the interface around them. The second is about the loop the developers use to make the agent better at building them. This one is about what those apps became once they stopped being one-offs and grew a place to live.
The through-line across all three is that Möbius has one job, to be as useful to you as it can. This post hands you the same reshaping power, with an app store as the on-ramp.
But the store is the small idea. The big one is that the agent does not build isolated apps. It grows a cross-app personal system that adapts to you. Your apps share a storage layer and a permission model, so the agent can compose them and reshape the whole thing around you over time. The store is how it starts. The agent living across all your apps is the point.
The primitives that make this work are small on purpose. An app is not a binary you trust and cannot inspect, it is a single file of source the agent (or you) can rewrite in place. An update is a new version of that file. Installing is a transaction the platform can roll back. The rest of this post walks those primitives one at a time, and marks where each is solid versus where it is still a plan.
The store is a starter pack, not a registry
The app store is itself a Möbius app. On first boot the platform installs it through the exact same path you use for everything else, the first sign there is no privileged install channel hiding somewhere.
.tex as you watch it typeset. 
What is in it today is a hand-picked set, not a gate you have to pass:
| App | What it does |
|---|---|
| News | A daily AI-curated digest. A background job wakes at 10:00, runs the agent with web search only, and writes the morning’s report. |
| Workout | A natural-language workout logger. Type what you did, like “3×5 deadlift at 100kg”, and it parses the sets. No agent, no cloud, all on your device. |
| Atlas | A draggable 3D globe; tap the countries you have been to and the count climbs toward 195. |
| Mind | An Obsidian-style graph of everything the agent has learned, every interaction and lesson, made browsable. |
| LaTeX | An Overleaf-style editor with a file drawer and a real tectonic engine; an AI sub-agent writes .tex while you watch it typeset. |
| Dreaming | Overnight, the agent interviews the day’s work and writes itself notes, so it starts the next day a little sharper. |
Each of those is a public git repo in the mobius-os organization, named app-<something>, with a mobius.json manifest, an index.jsx entry point, and a 1024×1024 icon. The smallest apps are that single file; larger ones pull in a few more, but the manifest plus an entry point is the whole contract. There is no submission queue and no registry to be blessed by. “Publishing” an app means making a repo public and sharing its manifest URL. The list above is a starter pack I picked. The install button takes any manifest URL you paste, and the store warns, but does not stop you, when it comes from a host it has not seen before.
index.jsx the app itself, one React component the agent wrote mobius.json the manifest: name, version, what it may reach icon.png a 1024×1024 icon job.jsoptional a background job, if the app has one What “install” actually does
When you tap Install, the work happens on the server in one transaction. The platform fetches the manifest (because that URL can point anywhere, it refuses private networks and cloud metadata endpoints and re-checks every redirect), then the app’s source, icon, background job, and any starter data it ships. It compiles off to the side and goes live only after the database row commits, so a half-written app is never something you can open. If anything fails, the whole thing rolls back and leaves nothing behind.
That all-or-nothing property is the foundation for the next two sections. It lets an update patch your app in place, and it lets recovery treat any break as something to undo.
Updates: version bumps you can see, data you keep
An installed app remembers the URL it came from, and that URL is its identity. Not its name, not a version number, the URL. The store periodically checks each app’s upstream manifest, and when the version there is newer than yours it shows an “Update available” pill.
Tapping Update reinstalls from the same URL. The backend switches into update mode and patches the parts that should change (the code, description, permissions, icon, schedule), then recompiles and remounts. Your data is not in that list. Starter data is only seeded for keys that do not exist yet, so an update can ship new defaults without trampling your logged workouts, your visited countries, your notes.
mobius.json One sharp edge is worth naming. If you ask the agent to customize an installed app and then tap Update, the update overwrites those customizations; there is no three-way merge. For a single-owner system that is a defensible default and a real trade-off. The direction I want is one git repo per installed app, so an update becomes a merge that carries your edits forward and a conflict becomes a chat where the agent resolves it. Designed, not built.
Recovery: breaking is allowed because it is reversible
An agent that can rewrite its own interface will eventually ship a CSS rule that hides the composer or a layout change that buries the drawer. The answer is not to wrap it in guardrails so it can never slip. The answer is to make mistakes cheap to undo. Recovery has three layers:
- A failed install cannot half-land. The atomic transaction from earlier restores the previous working version of the app from a snapshot. You do not get a corrupted app; you get the old one back.
-
/recoveris the bookmark you keep. It is a route rendered by a separate, server-side codepath the agent does not edit. It resets the shell to its baseline while keeping your chats, apps, and data. If a theme paints text the same color as the background, that page still works, because it does not go through the shell at all. - Your whole instance is a git repo. The agent commits the changes it makes to your shell, themes, app source, and schedules. When something breaks, the recovery path is the one a developer would use: read the log, find the change, restore it, except the agent does the reading.
/recover a server-side page the agent cannot edit; resets the shell, keeps chats, apps, and data There is no one-click “roll back this app to last week’s version” button yet. Recovery today is uninstall-and-reinstall, plus /recover, plus the git history. When an update breaks something, you tell the agent what went wrong and it walks the commit log back to the working version, the third layer run for you.
Recovery paths should make agent mistakes cheap to inspect and repair.
Your home screen, with or without Möbius
An app you install is not trapped inside the chat. Each one is also served at its own address, with its own web manifest and icon, as a standalone progressive web app. Add it to your phone’s home screen and it launches like any native app: full screen, no drawer, no chat. Workout opens straight to today’s session; Atlas opens to the globe.
Run standalone, an app has no Möbius shell around it to supply shared libraries, so the page vendors its own copy of React from your server. Nothing it needs lives on a CDN, which is what lets it render with the network off, the subject of the next section.
Offline, and the sync that catches up
“Works offline” is easy to claim and hard to land on a phone, so this is the part that got the most unglamorous engineering, and it holds.
When an app is marked offline-capable, a service worker caches the shell and the app’s code, so opening it with the network off renders the real app, not the browser’s offline page. Storage works offline for every app, not just the offline-capable ones. Reads come instantly from a local cache and refresh in the background; writes you make offline queue in a local outbox and sync the moment you reconnect.
So your data survives a dead connection, and I have checked it on a real phone, not a desktop pretending to be one. Two operations stay online by design (a cached listing could resurrect things you deleted, and chat is online-only). Conflicts are last-write-wins per item, which is right for a single owner and needs more thought for a shared one.
One system, not a pile of apps
Here is where the store stops being the point. Once your apps share a storage layer and a permission model, the agent is not stuck building each one in isolation. It can reach across them, compose them, and grow the whole thing around how you actually live.
Tweaking an app you have is real and easy. Open it, tell the agent what you want different (a darker palette, a new column, a weekly view instead of daily), and it edits the app’s source in place and recompiles. No fork button, no project to set up; the app is one file, and the agent edits that file the same way it would write a new one. It is the same loop as building from scratch, pointed at something that already exists.
Composing several apps into a new one is the next rung, and the full flow is not built yet. The idea is a health dashboard that reads across your workout tracker, calorie log, gratitude journal, and dream diary and surfaces the metrics you actually care about. The substrate exists. An app can declare that it reads another app’s data, and the backend enforces the handshake on both sides. But almost nothing uses it today, each app’s storage is scoped to itself by default, and there is no “build me an app that unifies these” flow. When I build it, this is the example I will build it against.
What actually drives this adaptation are the two apps I have barely touched here, Mind and Dreaming. Mind is the agent’s memory of everything it has learned across every interaction and lesson, not a profile of you but a record of what works. Dreaming is the overnight job that interviews the day’s work and feeds new lessons back in. Together they are how the agent gets sharper at fitting your system to you over time. They get their own post, your agent improves itself.
Building a good one, in practice
Two things make the difference when the goal is for the agent to build apps well, not just build them.
The first is the introspection loop from the companion post on the harness. Have the agent build one app, ask it why it made the choices it did while the transcript is still in front of it, and fold the answer back into its system prompt. Iterating the instructions is the lever, and introspection is how I find the edit worth making.
The second is the design phase, where I do not let one model decide alone. I drive with Claude and use the Codex plugin to adversarially review the design before the build starts. Two models disagreeing about an interface, a data model, or an edge case surface the questions a single model skips. The build is cheap, so the leverage is in the design.
a few rounds
The philosophy under all of it
Code empowers the agent; it does not police it. When the agent needs to install an app, write to your shell, or schedule a job, the platform’s job is to make that possible and reversible, not to second-guess it. Validators show up only where a failure would be silent and catastrophic; everywhere else the lever is a clear contract and a good recovery path, not a wall.
Low floor, high ceiling, no walls. A personal tracker that stores a little data and works offline should take one sentence, and an app that wants its own local database is free to reach for one. The one real wall right now is that apps cannot open arbitrary network connections to outside services, a deliberate security line I have not yet built a careful door through.
You own all of it. Your data is on a server you control. Your apps are files you can read. Your shell is a git repo you can revert. Nothing here is tuned to keep you engaged. The whole series has argued the opposite, an assistant whose one job is to be useful, that builds you the thing, gets out of the way, and leaves you holding something you can keep.
Where this goes
An app store was the obvious next thing once the agent could build apps reliably. The less obvious thing is what it turns Möbius into. A system where the unit of software is small enough for the agent to write, own, and repair, where installing and breaking are reversible, and where the agent turns “I wish I had a thing that…” into a thing that is there the next time you open your phone, then keeps reshaping it around you.
The apps above are a starter pack; the interesting ones do not exist yet. If you deploy an instance and build something, or tear one of these apart and rebuild it as something better, that is exactly the point, and I would love to see it.
The source is on GitHub, the app repos are under mobius-os, and the deploy button gets you a working instance in about three minutes. </content> </invoke>