Repo and folder scope

The coding scope in hilos is deliberately narrow per channel and per run. A hosted run loads only the repository linked to the channel where the work was requested, from a fresh clone or a scrubbed saved workspace. A local daemon resolves that channel's linked repository to a configured checkout, or uses that channel's explicit local-folder mapping.

The recommended setup is still one specialist agent per repository: it keeps identity and routing understandable. It is a setup pattern, not a hidden database restriction. If the same agent belongs to two repo-linked channels, work requested in each channel can reach that channel's repository.

The lists below come from the same scope source as the app's privacy panels. The hosted section describes the narrower credential used during a coding run; an idle, durable agent member keeps the workspace membership shown on its profile. These are enforced boundaries, not marketing.

Hosted agents

Runs on hilos in a fresh sandbox. It loads only the channel's repo, from a clone or scrubbed snapshot, and never touches your computer.

It can reach:

• The source room for this run — its messages and threads
• The repository you connect to a channel
• Workspace Docs, Tasks, and memory as project context

It cannot reach:

• Any other channel or direct message here — the run key is bound to its source room
• Your other workspaces
• Any repository other than the one linked to the channel
• Your API keys or what else you use AI for — hilos never passes them along

Local agents

Runs on your computer, in the folder you choose — exactly like opening your coding tool there yourself. hilos hands it the task and brings the changes back for review; it never sees hilos's own access token.

It can reach:

• This workspace's channels — and direct messages only if it's added to them
• The repository you connect to a channel
• The folder on your computer where you run it — the same access your coding tool already has

It cannot reach:

• Your other workspaces
• hilos's own workspace token — the daemon strips it from every run it starts
• Your API keys or what else you use AI for — hilos never passes them along

Eve agents on your own deployment

Runs on your own Eve deployment, wherever you host it. hilos forwards a mention and its thread context to your endpoint and posts the reply back; it never runs on hilos or on your computer.

It can reach:

• The messages that @mention it — in a direct message with it, every message — and the thread context sent with them
• Whatever your own Eve deployment does with them, on your endpoint

It cannot reach:

• Channels where it isn't mentioned
• Your other workspaces
• Your API keys or what else you use AI for — hilos never passes them along

Agents on your own cloud account

A Cursor Cloud agent runs on Cursor's cloud, on the Cursor account your workspace connected. It is the one kind that reaches the repository through someone else's authorization: you authorize Cursor's cloud on the repository in Cursor, once. hilos does not grant that access and cannot grant it for you.

Runs on Cursor's cloud on your Cursor account. It reaches the repository through Cursor's own GitHub authorization, which you grant in Cursor once — hilos reads the pull request, Cursor writes it. It never runs on hilos or on your computer.

It can reach:

• The task you @mention it with, and the thread context hilos sends along
• The repository you connect to a channel, through Cursor's own GitHub authorization — not hilos's
• Your own Cursor account, which runs the work and bills it

It cannot reach:

• Your other workspaces
• hilos's own workspace token — no run on Cursor's cloud ever carries it
• Your API keys or what else you use AI for — hilos never passes them along

The review gate

Every hilos-managed result comes back for your review. The first ready mini-app version becomes current automatically; repository work never merges, later mini-app revisions never become selected, and connected-resource proposals never replace the live or default state without a person's approval.

Approvals happen on the report card in the channel, so the room keeps an audit trail: what was asked, what the agent proposed, and who approved it.

Common questions

Why can't my agent see the repo? Check that the channel the agent is working in has a repository linked to it — use Connect in the channel header and choose Connect GitHub or a local folder. The agent's scope comes from that link; without it, a hosted agent has nothing to clone for repository work, and it will say so when you ask it to code there. A hilos-native page or small app can still start in the room without a repo. If the linked repo is brand new and empty, the coding agent adds a first commit itself to get started; if it can't because it lacks write access, it will ask you to push the first file.

Can one agent work across several repos? Yes, when it belongs to several channels and each channel is linked and configured. Scope never jumps between them during a run: the channel where the request starts determines the repo. For clearer expertise and auditing, prefer one agent per repo.

Does hilos see what else I use my coding tool for? No. Your API keys and your other work stay on your machine; hilos never passes them along, and a local agent never receives hilos's own access token.