LifeOS replaces a blank agent session with personal context
LifeOS installs a system prompt, skill library, memory structure, personal context, workflows, and optional dashboard around an existing AI coding harness. Its organizing idea is to record a person's current state and desired state, then route requests through skills and persistent context instead of starting from scratch each session. The README calls the personal profile TELOS and uses Cortex for memory, with Pulse as the local dashboard and service surface.
This is an unusually intimate tool. The USER tree can hold goals, contacts, preferences, projects, work history, and accumulated learnings. That may reduce repeated explanations and make long-running projects easier to resume. It also creates a concentrated record of a person's life and work. Anyone adopting it should know which files are versioned, what leaves the machine through model calls, and whether backups or remote repositories are private.
The 5-second npm install did not test the real installer
Our lab targeted the npm project under ./LifeOS/install/ at commit ce046f2. Installation took 5 seconds, added 2 packages, and used 2 MB. Npm-audit reported 0 known vulnerabilities across that resolved environment. The checkout contained 1,989 files and about 185,116 lines of source. Those figures describe a small package step inside the repository, not a functioning personal agent setup.
There was no build script or target and no test script or target, so both phases were skipped. Our unprivileged Node 22 container had 3 CPUs, 8 GB of RAM, and no secrets. We did not run the Bun installer, alter a harness profile, launch Claude Code, fill in personal data, start Pulse, or verify hooks. The lab result therefore says almost nothing about day-to-day LifeOS behavior.
What happened when we ran it
Our sandbox installed 2 npm packages in 5 seconds and consumed 2 MB. The audit found 0 known vulnerabilities. With no build command and no test command exposed at the measured project path, there are no build or test results to report. The repository scan found 2 CI workflow files, no Dockerfile, and no tests directory.
That gap matters more here than it would for a static prompt collection. LifeOS changes how an agent loads instructions, writes memory, runs hooks, and handles personal state. A meaningful evaluation needs a fresh harness profile, a documented install plan, synthetic personal data, restarts, upgrades, and rollback checks. None of those happened in our sandbox, so the published 5-second number should not be mistaken for setup ease.
Claude Code gets full hooks; other harnesses get a reduced mode
The install guide names Claude Code, Cursor, Cline, Codex, Gemini CLI, and other capable coding assistants. The result differs by host. Claude Code on macOS, Linux, and Windows gets native always-on hooks for response formatting, memory, and per-turn context. Other harnesses receive the LifeOS tree plus an AGENTS.md or equivalent context file, while workflows run on request and always-on hooks remain roadmap work.
That is honest documentation, and buyers should take it literally. LifeOS describes itself as harness-agnostic, but Claude Code is the tested path and the foundation credited in the README. The claude-code tag is therefore necessary. A Codex user may still use the skills and context, but should not expect the same event hooks or runtime behavior until the project says those pieces ship.
Installation modifies configuration after explicit approval
The AI-led installer first detects the host, scans for conflicts, and runs deployment tools in dry-run mode. Applying the plan copies the runtime into the harness configuration and creates a USER tree. Claude Code integration then merges hooks into settings.json, activates imports, and wires a lifeos shell command that starts Claude with the LifeOS system prompt. Optional components include a status line, agents, Pulse, and background jobs.
The guide repeatedly requires showing each change and getting permission, which is the right model. Users should still read the plan rather than delegating judgment to the same agent being modified. The README also offers curl ... | bash; that shortcut is convenient, but a version-pinned download inspected before execution is easier to audit. Back up the harness configuration and keep the first trial separate from a daily profile.
A fresh-install memory bug blocks a carefree recommendation
Open issue 1972 reports that version 7.40.4 fails to create the LIFEOS/MEMORY symlink during a fresh install. According to the reproduction, later writes create a real directory inside the system tree, while the intended USER memory remains invisible. The archive still answers queries against empty data, so the failure can look like a working memory system that simply remembers nothing.
The issue was opened August 24, 2026 and remained open when fetched. Other current reports describe disagreement about where TELOS content belongs, relocated installs writing to the default path, and security guards that can misclassify or permit public pushes. These are specific, useful bug reports and evidence of active scrutiny. They also touch the exact boundaries that protect personal context, so new users should wait or reproduce the fixes in an isolated profile.
Release activity is healthy despite no push after August 14
GitHub recorded 18,740 stars, 78 combined issues and pull requests, and a last code push on August 14, 2026. Release v7.40.4 shipped that day. Issue discussion continued through August 24 with detailed fresh-install and security reports, so the project is not abandoned; the code snapshot simply has not incorporated all current findings. GitHub activity and release date need to be read together here.
LifeOS has a compelling premise for one kind of user: somebody already living in Claude Code who wants that agent to remember far more. The cost is a large trust boundary around personal data and harness configuration. Trial it with synthetic context, review the generated paths, test recovery, and keep the repository private. Until fresh-install memory placement is fixed, the main profile should stay untouched.