Star Office UI: a pixel office dashboard for OpenClaw agents

What Star Office UI actually shows you

An agent's work is invisible. It reads a file, runs a command, waits, fails, retries, and none of that produces anything a human can glance at. Star Office UI's answer is a pixel-art room: characters walk to a desk, a sofa or a bug area depending on what the agent reports, with a speech bubble carrying a short description. The README frames the goal as seeing "who is doing what, what they did yesterday, and whether they are online right now."

The audience is narrow and clearly stated. If you run OpenClaw, the README calls that the complete experience, because the agent switches its own state as it works. If you do not run OpenClaw, the project still deploys, and you drive it with set_state.py or with HTTP calls from anything that can send a request. That second group is the one worth thinking about, because a status board fed by hand is a different product from one fed automatically. It works, but the value depends entirely on whether you wire something up to push into it.

Six states, three zones, and a Flask process behind them

The mechanism is a state file plus a small Flask service. The backend reads state.json, the frontend polls it, and the pixel scene moves the character to whichever zone the state maps to. The mapping is documented as a table: idle goes to the rest area, error goes to the bug area, and writing, researching, executing and syncing all go to the work area. So six states collapse into three visible locations, and four of them look identical from across the room. That is a deliberate simplification, but it means the bubble text carries most of the actual information.

A second data path feeds the yesterday memo. The backend reads the most recent day out of memory/*.md, strips it down, and renders it as a card. The README does not describe the redaction rules, so if your memory files contain anything sensitive, read the code before you enable that view.

Multi-agent support is a separate flow. A join key, generated at first startup from join-keys.sample.json into a runtime join-keys.json, lets a guest agent push its own state. The README states each key supports up to three simultaneous agents by default. Guests run office-agent-push.py with three variables filled in and it pushes every 15 seconds. The API surface behind all of this is small and flat: /health, /status, /set_state, /agents, /join-agent, /agent-push, /leave-agent, /yesterday-memo, plus Gemini config and image-generation polling endpoints.

Installing Star Office UI and setting your first state

The README gives a manual path that assumes Python 3.10 or newer, because the code uses the X | Y union type syntax. On 3.9 or below it will not run. Clone, install the backend requirements, copy the state template, then start the Flask app from the backend directory.

git clone https://github.com/ringhyacinth/Star-Office-UI.git
cd Star-Office-UI
python3 -m pip install -r backend/requirements.txt
cp state.sample.json state.json
cd backend
python3 app.py

After that, the README points you at http://127.0.0.1:19000. The port matters: the changelog for 2026-03-06 records that the default moved from 18791 to 19000 specifically to avoid a conflict with OpenClaw's Browser Control port. If you have notes from an older setup, that is why the number changed.

The state script takes a state name and a description string. The README shows four invocations, and the character should move to the matching zone as soon as the frontend picks up the change.

python3 set_state.py writing "正在整理文档"
python3 set_state.py syncing "同步进度中"
python3 set_state.py error "发现问题，排查中"
python3 set_state.py idle "待命中"

There is also a smoke test script, which is more than most small dashboards ship. It takes a base URL and prints OK for each check that passes.

python3 scripts/smoke_test.py --base-url http://127.0.0.1:19000

The art licence is the constraint that will bite you

This is the part to read twice. The repository splits its licence: code and logic under MIT, art assets non-commercial only, for learning, demonstration and exchange. The README is explicit that commercial use requires replacing every art asset with your own original material. The repository's licence field reads NOASSERTION, which is consistent with a project that has a LICENSE file for the code but a different, stricter term attached to the assets directory.

Guest character animations come from LimeZu's free Animated Mini Characters 2 pack, and the README asks that you keep the attribution when you redistribute or demo. If you are evaluating this for anything that touches revenue, the honest position is that you are evaluating the backend and the layout, not the visuals. Budget for an artist.

Production hardening is the other operational cost. The .env.example marks STAR_OFFICE_ENV=production to enable startup checks, and requires FLASK_SECRET_KEY at 24 characters or more plus an ASSET_DRAWER_PASS that the file explicitly says should not be 1234. The changelog for 2026-03-04 describes weak-password blocking, session cookie hardening and automatic return to idle from stale states. Configuration is read from .env, and Gemini settings can also be written at runtime through the UI or the config endpoints.

Where Star Office UI is the wrong tool

The desktop pet is the clearest example. It lives in desktop-pet/, runs through Electron, and the README labels it an optional experimental feature developed mainly on macOS by a contributor. It auto-starts the Python backend and points the window at http://127.0.0.1:19000/?desktop=1. Treat it as a demo, not as something to put in front of a team.

cd desktop-pet
npm install
npm run dev

Because four of the six states render in the same work area, the office is a presence indicator, not a monitoring tool. It will not tell you that an agent is stuck in a retry loop, and it has no alerting, no history chart and no threshold. If you need to know when something breaks, this is the wrong layer and you want real observability next to it. The yesterday memo is the other thing to check before enabling: it reads from memory/*.md, and the README says the content is redacted before display but does not document how. Until you have read that code path, pointing it at a directory of real working notes is a decision, not a default.

How it compares to a plain status page or a terminal dashboard

The obvious alternative is a generic dashboard or a terminal status page driven by the same HTTP calls. The difference is the data model. A generic dashboard asks you to define panels, queries and thresholds, and it renders numbers. Star Office UI ships a fixed scene with a fixed state vocabulary baked into the frontend, so setup is one clone and one pip install, and the cost is that you cannot add a seventh state without editing the frontend yourself.

A terminal tool like a tmux pane or a small curses script has the opposite profile: zero browser, zero art licence question, and it fits inside an SSH session. If you already live in a terminal, Star Office UI's value is mostly social. It is a screen you can leave open on a second monitor or on a phone, which the README lists as a supported use case, and that is a real difference from a dashboard nobody looks at.

Editorial conclusion

Adopt Star Office UI if you already run OpenClaw agents and want a passive, glanceable view of their state, or if you want a pixel status page driven by any HTTP client. Do not adopt it if you need commercial use of the shipped art, if you are on Python 3.9 or older, or if you expect the desktop pet to be a finished product. Before deploying past localhost, verify two things: that FLASK_SECRET_KEY and ASSET_DRAWER_PASS are set to long random values in .env, and that every art asset you keep is one you have the right to ship. The last push to the repository was on 2026-03-11, so treat the code as a stable snapshot rather than something being changed under you.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. ringhyacinth/Star-Office-UI on GitHub