A project folder is a Project Location
LoneAct does not maintain a logical project object that spans devices. It recognises a real directory on a specific runtime: that directory plus the device running it form a Project Location. Conversations, Agent teams, file scope, and tool execution are all bound to that Location.
Endpoint
A LoneAct runtime installation on one device. It has its own identity and key pair; one device can host multiple project folders.
Project Location
An immutable project root on a runtime, with its display name, state, rules, and capabilities.
ProjectLocationRef
The stable resource key made of endpointId + projectLocationId; every command uses it to address a project.
Even when two folders share a name, come from the same Git remote, or look similar, they remain two independent Locations. File writes, commands, and grants can never land on the wrong machine.
One device, many projects
The Locations sidebar in Local Web and the IDE groups projects by device. You can add multiple project roots on the same computer, and each project keeps its own Conversations, Agent Team, Memory, Rules, Secrets, and checkpoints.
Local and remote projects
Local Web and the IDE can mount two execution paths at once: local projects use the Direct Endpoint, while remote projects use Cloud Relay. Cloud Web mounts Cloud Relay only. Both paths share the same Workbench model, but tools always execute on the device that owns the project.
| Entry point | Local projects | Remote projects | Where tools run |
|---|---|---|---|
| Local Web | Direct | Cloud Relay (after remote access is configured) | The owning Endpoint |
| IDE | Direct | Cloud Relay (after remote access is configured) | The owning Endpoint |
| Cloud Web | — | Cloud Relay | The owning Endpoint |
The cloud discovers, authorises, and relays. File access, terminal commands, browser actions, and MCP tools still run on the owning runtime. When that runtime is offline, the project summary remains visible, but actions that need execution are disabled with a stable reason.
Same-account discovery and cross-account grants
Same account: automatic discovery
A remote-enabled device publishes its Locations. Other devices or Cloud Web signed in to the same account see those projects without creating a Grant for each one.
Same accountCross-account: explicit Grant
Sharing a project with another account creates a RemoteAccessGrant scoped by Location and capability. It can be revoked and leaves an authorisation record.
Explicit grantWhen a remote device is offline, its project summaries and latest state remain visible. Opening files, creating conversations, or executing tools shows a stable blocked reason until the device is online again.
A typical mixed workbench path
Open Locations
Local Web and the IDE group visible projects by device; Cloud Web lists Locations published by the same account and by accounts that granted access.
Select a project
Conversations, the file tree, the team, and settings switch to that Location's context.
Start work
Create a Conversation and state the goal, constraints, and acceptance criteria; the model and tool snapshot resolve against the current project.
Switch as needed
Move to a project on another device in the same window; conversations and run records stay with their original Location.
Boundaries and guidance
- Do not add your entire home directory as a project; use the real project root and keep the Repository allowlist narrow.
- Archiving and re-adding the same folder creates a new Location ID; old conversations do not migrate to the new directory automatically.
- A remote project needs its owning Endpoint to be online; Cloud Web cannot execute local tools on behalf of an offline device.
- Use revocable Grants for cross-account collaboration and grant the smallest scope; do not share personal accounts.
- Prefer Local Web or the IDE when you need the full local toolset; Cloud Web is for continuing work remotely and reviewing state.
Next: read Local Web and Cloud workbench to see how both entry points connect to the same set of projects.