Known limitations

Platform verification#

The Linux CLI installer is exercised in a container through setup, doctor, pglite, services, migrations, and concurrent reads. It has not been validated on real Linux hardware or through a real user systemd bus.

The Linux desktop packages are built and have not been installed on real hardware. On Windows the desktop app works end to end, with the toryo CLI and services inside WSL2; its installer is not signed yet. See Linux & WSL2 and Windows.

Updates interrupt active work#

Updates restart background services. The CLI refuses a busy update with exit 68 and Board disables its update action until work drains. --force is available, but intentionally ends active agent and dispatch work. Intel Macs still update Board by replacing the dmg manually.

To drain first, pause dispatch admission (toryo dispatch pause); running work finishes and nothing new starts until you resume.

Local runtime switching does not migrate data#

Docker and pglite keep separate stores. Changing TORYO_DB_RUNTIME points toryo at the other store; moving existing data requires a dump and restore. pglite also serializes queries per database, which can constrain heavy concurrency. External PostgreSQL is selected with TORYO_DATABASE_MODE=external, not by switching TORYO_DB_RUNTIME; moving data to or from it also requires a database dump and restore.

Agent sessions do not resume on retry#

After a failed step, every supported harness starts a new agent session rather than resuming the process that died. A dispatch job can explicitly continue an earlier Claude Code session, but a sequence retry does not use that. Harness capabilities otherwise differ and continue to evolve; use Harnesses and the generated reference for the current matrix.

Runs and isolated worktrees persist through process and machine interruption, and an approval gate can wait while the machine is asleep. Execution itself requires the local machine to be awake. Retrying a failed step re-arms it and starts the fresh harness session described above.

Host and local-service boundaries#

toryo needs at least one installed, authenticated coding agent plus git and tmux. The coding sequence also needs an authenticated GitHub CLI. Setup can install it. toryo doctor reports missing prerequisites.

Ollama is optional. Without it and both required models, semantic search falls back to keyword matching and global memory writes queue for review. An external Ollama that stops answering is reported unavailable, and toryo keeps running without brain enrichment.

Claude Code workers do not load your personal Claude Code settings, instructions or user-level MCP servers by default. See Harnesses.

The MCP server is local stdio, not a remote endpoint. Claude Desktop has no working directory from which to infer a project, and some destructive, interactive, or lifecycle commands are deliberately withheld from toryo_run. See MCP.

Scheduling#

The scheduler runs locally. The machine must be awake at the scheduled time, and a missed window is not replayed.

Where knowledge lives#

Your own knowledge, global and your own projects, is kept on the machine where it was saved. It does not sync between your machines.

Until a team enables hosting, its members do not share saved project knowledge. Enabling hosting carries what members saved with it. Switching between hosted services, or back to members' machines, keeps the previous service readable for 14 days while toryo copies the team's knowledge across; anything not copied by then stays only on the previous service. Moving a self-hosted server to a new address does not transfer existing knowledge.

Self-hosting your team's knowledge needs the Enterprise plan. See Where your team's knowledge lives.