Do's and don'ts for working safely with Rojos (Roject's AI agents) - what to review before granting broad access, and how to keep your work recoverable if an agent gets something wrong.
Rojos can take real actions on your behalf - reading, writing, moving, or deleting files, and running terminal commands. Like any agentic system, they can be wrong, incomplete, or do something you didn't expect. None of the practices below are mandatory, but each one directly reduces how much a mistake can cost you. For a categorized breakdown of specific risks and how severe they are, see our Risks page.
Any text a Rojo reads - a file, a web page, a tool's output, even a filename - can contain instructions disguised as ordinary content. An agent that treats everything it reads as trustworthy may follow hidden instructions instead of yours, especially in files or data that didn't come from your own direct input.
You're responsible for reading and understanding text before you rely on it - both what an agent writes for you (code, documents, messages) and what an agent reads on your behalf. Careful reading is your main defense against both plain mistakes and hidden instructions in source content.
Keep your own backup of anything you're not prepared to lose, before letting a Rojo make a large or risky change. Version control (git or similar) is the easiest way, since it costs nothing extra once set up and lets you review a diff before reverting - but any backup method works. This isn't optional for anything that matters to you.
For anything destructive or hard to reverse - deleting files, mass renames, force-pushing, rewriting many files at once - ask the Rojo to explain its plan first, or have it make the change to a small part before applying it everywhere.
Rojo Chat shows tool calls - file reads/writes, terminal commands - as they happen, not just the final answer. Keep an eye on them, especially before approving anything that touches files or runs a command you didn't explicitly ask for.
A Rojo can act anywhere inside the project you point it at. Keep credentials, unrelated personal files, and anything outside the project's own concern out of that folder, rather than relying on the Rojo to know not to touch them.
Components, workflows, actions, or configurations shipped with Roject that expose instructable or actionable content to agents/LLMs - prompt templates, tool definitions, workspace actions - should be treated as untested blueprints, not verified-safe defaults. They're ready to be reviewed, not ready to be trusted blind. Read and understand what one actually does before granting it broad access or relying on it.
A Rojo is backed by an external program - a local model process, a spawned CLI, a connection to a remote provider - not something Roject fully controls. Like any external software, it can crash, hang, become buggy, or simply stop responding to Roject's own instructions. Closing the panel or even the whole app is usually enough to stop it, but isn't guaranteed - an already-misbehaving external process can keep running regardless. If that happens, check your system's process list directly.
A session can be badly initialized or take a strange turn partway through: acting overconfident, making repeated errors, ignoring your instructions, failing to use tools or context correctly, or otherwise behaving unlike its normal pattern. Treat this as a hazard, not something to talk the session back out of - restart it immediately rather than continuing to work with it or approving its actions.
Terminal sessions, static servers, and subprocesses a Rojo spawned can keep running after their panel, session, or even the app itself closes - from Roject's own processes as well as anything an agent started. Left running, they can hold ports open, keep using resources, or in rare cases keep acting. Periodically check your system's process list for anything Roject-related that should have stopped, and end it manually if it's still there.
Some features - the Static Server panel, video calls, the experimental tunnel.rokojori.com - open network ports or ask for firewall exceptions to work, which can expose a local service more broadly than you intended. Only open what you need, close it when you're done, and avoid running exposed services on networks you don't control.
A Rojo connects to whatever model or provider you've configured it with - your own API key, a local model, or a local Claude Code CLI installation. That provider's own behavior, reliability, and terms apply on top of everything above; see Terms of Service, Section 6.