Autonomy & Safety

Elowen can plan, make changes, delegate work, and run workflows. Each action remains subject to the current account's access, Project, tool grants, and permission rules. Delegated work inherits its caller's access and can only narrow it.

Choose a work mode

In Web chat, open Options in the composer and choose a mode under Work mode. In elowen chat, use one of these commands:

/plan       Plan before making changes
/build      Make changes with tools
/workflow   Coordinate dependent sub-agent tasks

Plan mode lets Elowen use any tool that only reads, and write or edit the conversation's plan file and nothing else. The shell runs only non-destructive commands, and anything delegated from a planning turn runs read-only. That is a guardrail, not a filesystem sandbox. Choose Implement plan to switch to Build mode, or Keep refining to stay in Plan mode and refine the plan.

Set tool permissions

Open Account → Models → Command permissions to create rules for Bash commands and tool names. Each rule can Allow a call without asking, Ask for approval, or Deny it. Rules can use * as a wildcard; the last matching rule wins. Put broad rules first and specific exceptions after them.

git status*    Allow
rm *           Deny
Write          Ask

Built-in safety rules still apply. Always allow on an approval prompt saves a matching rule in this editor. A tool rule cannot grant a tool, Project, or permission you do not otherwise have.

Approval in unattended runs

In Web or CLI chat, an Ask rule waits for your approval; cancelling refuses the call. Scheduled jobs, platform channels, and sub-agents have no person available to answer. Unattended runs in Account → Models decides whether these asks are allowed or blocked; the default is Allow. Explicit Deny rules still refuse a call.

YOLO mode automatically approves asks in new sessions. The Account → Models toggle is the default for new sessions; CLI commands change only the current conversation. In elowen chat, /yolo toggles the current session, while /yolo on and /yolo off set it directly. YOLO never overrides a Deny rule or unattended Block mode.

Keep delegated work within scope

A sub-agent cannot gain Projects, tools, or permissions the caller does not have. DelegateContinue resumes the child's conversation and checks its current access against the caller's. From Plan mode, that follow-up runs read-only and only while the child is idle. A different model does not grant more access.

The read_only: true option removes write tools and blocks common destructive shell commands. Shell redirection can still write files reachable by the daemon user, so this is not a filesystem sandbox. Use a managed Project environment when work needs its own isolated filesystem. Only the same caller can promote a child that they explicitly requested as read-only, using write_access: true; a read-only limit imposed by Plan mode or the child type cannot be lifted. A delegated child does not inherit the parent's personal memory identity.

A workflow runs dependent steps in order and independent steps in parallel. Each node receives a short handover from direct prerequisites. Elowen attempts to recover unfinished work after a restart; if it cannot verify the required access, it stops or parks the work instead of replaying it under broader authority. See Sub-agents & Workflows.

Projects, accounts, and shared rooms

A conversation can use only Projects available to its current account. In a shared room, access follows the verified account of the person sending the current request; Elowen does not guess an account for an unlinked sender. Removing Project access or a tool grant does not create a broader fallback.

A managed Project runs commands in its own environment. On host Projects, non-operator commands are confined by default to the account's accessible Projects and private HOME; network access remains available. If the confinement check fails, the command is refused. An operator can turn off Confine non-operator commands in the Environments (sandbox) plugin's Execution section to allow granted non-operators to run commands directly on the host. That setting is on by default. It does not control commands inside managed Projects. See Projects, Environments & GitHub.

External actions need the right authority

Publishing code, merging pull requests, sending messages, deploying, and restarting shared services require the authority and confirmation for that action. An approval prompt alone does not grant authority. GitHub changes are ordinary git and gh commands. A terminal command is signed in to GitHub only when the account running it holds the Project's repository mapping.

For account settings, see Your Account & Preferences. For plugin access, see Plugins.

Next: Projects, Environments & GitHub