Hello everyone, I want to share my experience over the past six months building an open-source web application system (with the help of Cloud Code and Codex). The system is real, not just a UI; everything you see here was built as an application on top of the system and is not part of it. Plus, it continues to work even if you close the browser (unlike Puter, for example).
source
https://github.com/PhreshOS/system
demo (around 5 people at a time, if it's full there's a timer)
docs
how can I benefit from it? I build all my own tools on top of it, thus benefiting from remote access, a single authentication system, and communication. All I write is the business logic and how the interface will look. Any AI agent can access and use this application without me having to build a custom interface for it.
Top comments (6)
Persistent execution after the tab closes is the right differentiator for a browser-only workspace. From the agent side the interesting part is the API surface: if any AI agent can drive the app without a custom interface, then stable primitives like start/status/output per job matter more than the UI. One concrete question that would help evaluate it: when a session reconnects after the tab closed, does it reattach to the same job ID and stored output, and does a long-running job keep executing server-side if authentication expires mid-job?
The system runs as a single entity on the server and owns all the processes. The browser is just a way to connect to it. Sessions are the mechanism for managing authentication, so losing the connection or having a session expire doesn’t change the server’s state. The CLI is just another way to connect to the same system from the machine itself.
Let me explain the idea a bit more clearly.
The system manages and runs application processes, while the browser is just one way to connect to it. It also provides an SDK and APIs that applications can use to access system state and services.
The two points you mentioned are actually the responsibility of the applications built on top of the system. The system provides the infrastructure and APIs, but each application decides how to handle these situations.
Regarding recovery after a restart, if the system crashes or restarts, it's up to the application to preserve its state and resume its work. Application processes have direct access to the host environment unless they're running in sandbox mode, which is optional. They can use persistent storage directly, or use the APIs provided by the system for file storage, databases, and key-value storage.
Applications can use these to save their state and resume work after a restart. They can also declare startup processes that the system will automatically launch when it starts again. So the system provides the tools, but the recovery logic is handled by the application itself.
As for tracking who initiated an operation, the system provides APIs that allow applications to access the session associated with the connection making a request. An application can associate that session with the operation and keep its own records, even after the session expires. How it records and manages that information is up to the application.
The general idea is that the system handles the common infrastructure: authentication, communication, and application process management. Applications are responsible for managing their own resources and state, recovering their work after restarts, and keeping their own operation logs.
That's the separation I'm trying to maintain. The system provides the infrastructure, but it doesn't decide how each application should behave.
The "keeps working after the browser closes" part is the distinction I'd want to see demonstrated. If an app starts a long-running job, then the tab closes and reconnects, does it reattach to the same job ID and stored output? A short demo showing that path, plus what happens when authentication expires mid-job, would clarify the execution lifecycle more than another desktop screenshot. I haven't run the demo, so this is a question about the contract rather than a claim about its behavior.
Creating a video explaining the concept is part of the plan, but here's a brief overview:
Every application consists of two parts: a server and a client, connected by a two-way communication channel.
The idea is that the state remains on the server side of the application, while the browser interface only displays that state. There are other solutions for simpler uses.
Generally, this documentation covers everything. If you give it to GROK AI along with your use case, it will tell you if it will help you.
phreshos.com/docs
Here's a general explanatory video:
phreshos.com/media/phreshos-deskto...
That boundary is exactly where I would want it: liveness attached to the process instead of the connection means a dropped tab or an expired session can never silently kill work, and the failure domain is one thing you can actually monitor - the server entity - instead of N client connections.
Two follow-ups that design implies. First, what supervises the single entity: if it restarts mid-run, do in-flight jobs resume from persisted state or die with the process? A supervisor plus a durable job record is what makes 'the server owns the processes' survive a reboot instead of being an assumption. Second, your answer means that when a session expires mid-operation, the operation keeps going and only the observation goes away. If so, actions can complete after the credential that started them is gone - which is the part I would want covered in the audit story: the log carrying its own attribution (which identity started it, what it touched) instead of borrowing it from a live session.