Skip to main content
Contents

Work with RX Projects

RX Projects keeps a goal, a chosen folder, RX's lead chat, worker chats and task results together in Ouros X. This guide covers the local candidate, which is not available from the public stable channel. Projects are saved on your Mac. They do not run in the cloud or keep working after Ouros X quits.

Start a project​

  1. Open the native Workspace and choose RX Projects, then New project.
  2. Enter a name and a concrete goal.
  3. Choose the project folder. Use a folder containing only material the project should access.
  4. Choose Create project. The goal is saved and queued while the project stays paused for worker setup.
  5. Add your workers and review their scopes, then choose Resume once. RX runs the saved goal without requiring you to submit it again.

Connect your Ouros account​

Sign in to your Ouros account in the app before starting project work. RX Projects uses that signed-in account. It has its own connection; you do not need to change the provider selected for Personal Assistant or ordinary chat. Choosing a local provider for those conversations does not select the project's connection.

The app can keep private project state in the existing Ouros workspace configured in Settings when that workspace uses a linked folder. This does not widen workers' access to files.

If project work reports a sign-in or connection problem, check the signed-in Ouros account before retrying. Do not switch the ordinary chat provider to fix project setup. Creating a project does not grant additional account access or permissions.

Give workers a scope​

Choose Add worker. Set a name, role and instructions, then enter allowed paths relative to the project folder, one per line. Choose specific files or subfolders, such as docs or artifacts; paths cannot leave the project folder.

Workers start with text-file reading and directory listing. Enable Allow file writes only when that worker needs to create new output files. Writes can only create new files in existing directories; they cannot overwrite files or create folders. Project workers have no shell access. RX coordinates the workers but has no file tools of its own. The saved tools and paths are enforced when work runs, not just included in its instructions. Existing permissions still apply.

Use a local folder you own, not your home folder or a system directory. Hidden files, credential paths and linked files are excluded. Text-file reads and writes are limited to 64 KiB; a refusal is not permission to widen the worker's scope.

The Team list opens the saved chat for RX or an individual worker. Instructions and scope shows each worker's saved limits. Sending a worker a different instruction does not widen those limits.

Assign and review work​

Use Assign to to choose RX or an enabled worker, enter a task and choose Add task. While paused, choose Queue task instead; the task waits until you resume. Once the project has enabled workers, RX can split its goal into bounded assignments and collect their results in a final response. To continue after a run, assign a follow-up goal to RX. After the current run finishes, RX can plan another set of tasks with the same saved workers. Those worker assignments use the follow-up goal, not the original project goal. Earlier goals, conversations and results remain available. Delegation can use only saved enabled workers; it cannot add workers or widen their permissions. Review each task's state and result under Activity, and use Open chat for its conversation. Show full result expands a longer answer.

RX checks its plan before starting workers. A complete JSON plan can be wrapped in a JSON code block, but surrounding prose, unknown workers or invalid dependencies are not accepted. A planning error does not grant workers more tools or wider paths. Read the error and review the saved workers and task before retrying.

A completed answer is not proof that a file is correct. Inspect changed files and run the checks appropriate to the task before relying on the result.

Pause, cancel and recover​

  • Pause stops the project from starting more work. An already running task can finish. Tasks added while paused remain queued; Resume allows queued work to run again.
  • Cancel task requests cancellation of that task's current attempt; check its displayed state. Cancellation does not undo files already written or requests already sent.
  • Awaiting approval means the task needs a decision. Choose Review in chat rather than submitting the same task again.
  • After an interrupted run, review the task and its files. Use Retry deliberately for an interrupted, failed or cancelled task; it starts a new attempt and can repeat earlier actions.

Retrying a worker keeps completed peer tasks intact. RX collects the current attempts into a fresh summary; it does not silently rerun completed workers or widen their saved scopes. Earlier summaries remain in the saved history, so check the current task states and latest summary. See interruption recovery before repeating work with an uncertain outcome.

Saved projects, roles, chats and results survive reopening the app. Saving them does not keep a running process alive. Keep Ouros X open for execution; there is no automatic cloud failover, always-on service or promise of work continuing while your Mac is asleep.

If the connected account changes, return to the project's original connection before resuming. If a project cannot be saved or opened, read the displayed error before retrying. Do not delete its saved data to clear a connection or permission problem.