Scope
Scope
Scope controls which chats and users share runtime workspace files, attachments, memory, and skills.
Config
createHeypi({
state: { root: "./state" },
// ...adapters, agent
scope: "channel", // default: "channel" | "user" | "adapter" | "agent"
runtime: {
root: "./workspace",
// scope: "user", // optional runtime/workspace override
},
memory: {
enabled: true,
scope: "user", // optional memory override
},
skills: {
enabled: true,
scope: "channel", // optional skills override
},
});Options
| Option | Required | Default | Description |
|---|---|---|---|
scope |
No | "channel" |
Default scope for scoped features. |
runtime.scope |
No | Top-level scope |
Runtime workspace override. |
memory.scope |
No | Top-level scope |
Memory override. |
skills.scope |
No | Top-level scope |
Skills override. |
Levels
channel: one scope per Slack channel, Telegram chat, Discord channel, or webhook channel.user: one scope per chat actor.adapter: one scope per configured adapter instance.agent: one scope across adapters for this configured agent.
Sessions, chat history, approvals, and active-run locks remain per thread. Scope controls shared working context, not the conversation identity.
Use adapter or agent only when you intentionally want one conversation to affect another through shared files, memory, or skills.
Overrides
The top-level scope is the default for scoped features:
- Runtime workspaces follow
runtime.scope ?? scope. - Memory follows
memory.scope ?? scope. - Skills follow
skills.scope ?? scope. - Attachments follow the top-level
scope; there is no separateattachments.scope.
This lets you combine shared channel files with per-user memory, or per-user workspaces with shared channel skills.
Layout
Scoped data lives under the configured runtime root:
workspace/
scopes/
channel/<agent>/<provider>/<team>/<channel>/
user/<agent>/<provider>/<team>/<actor>/
adapter/<agent>/<provider>/
agent/<agent>/
attachments/
scopes/
channel/<agent>/<provider>/<team>/<channel>/
memory/
scopes/
channel/<agent>/<provider>/<team>/<channel>/memory.md
skills/
scopes/
channel/<agent>/<provider>/<team>/<channel>/<skill>/SKILL.mdSecret handoffs are written into the active runtime workspace as .secrets/<name>, so they follow runtime scope rather than memory or skills scope.
Path segments are encoded before they are used on disk.
Attachment refs are resolved only against the current scope. A channel-scoped app cannot use an attachment uploaded in another channel, and a user-scoped app cannot use another user's uploaded file.
The built-in attach tool uses the active runtime scope, so generated files are uploaded only from the current scoped workspace.
Host-based runtimes (host-bash, guarded-bash) are not hard filesystem sandboxes. Use just-bash, Docker, or Gondolin for team-facing isolation.