EONYX permissions and security: control over every action

An agent reads code, edits it and runs commands.
So it has to stay inside explicit permissions.
EONYX stacks several layers: a static gateway, a file sandbox, plan mode and a hard block on dangerous commands.

1 🚦 The permission gateway

1.1 Static policy

Tools split in two.
Always allowed are the read-only ones.
Requiring permission are writes, commands, commits and MCP tools.

No questions asked for read, ls, glob, grep, git_status, git_diff, git_log, todo_write.
Everything else meets the gateway:

"permissions": {
  "allowed_tools": ["bash", "write", "edit"],
  "sandbox": true
}

• allowed_tools — tools that run without confirmation.
• sandbox — locks the file tools inside the project root. More below.
• --yolo, or /yolo in the TUI — allows everything for this session.

If a tool is not allowed and --yolo is off, the policy denies it: “permission denied for tool …: re-run with –yolo or add … to permissions.allowed_tools”.

1.2 The interactive layer in the TUI

Interactive mode adds a dialog on top of the static policy.
When the policy refuses a tool, EONYX asks:

• Allow once — this one time.
• Allow always (this session) — until the session ends.
• Deny — reject it. Esc means deny.

“Allow always” remembers the tool for the session, so it stops asking.

1.3 Plan mode

/plan is a stricter think-first gate.
While it is on, only read-only tools run: read, ls, glob, grep, picker, git_status, git_diff, git_log, fetch, task, todo_write.
Anything that writes or executes is blocked, regardless of allowed_tools and --yolo:

plan mode is on: “…” is blocked until you approve the plan — run /plan to exit plan mode and enable edits

When the plan is ready a dialog appears: implement, allow edits, or keep planning.
Handy when you want the agent to study the code and propose a plan before touching anything.

2 🧱 Boundaries and guardrails

2.1 The file sandbox

permissions.sandbox: true locks read, write, edit, multi_edit and ls inside the project root.
That is the directory holding eonyx.json, or the working directory if there is none.
A path outside it is refused:

path “…” is outside the project sandbox (…); set permissions.sandbox to false to allow paths outside the project

The sandbox is off by default.
Turn it on for an untrusted task, or when you want a guarantee that nothing outside the project is touched.
Tools with no path argument are unaffected: bash, glob, grep, fetch and the git tools.

2.2 Blocking dangerous commands

Below the gateway sits one more, coarser layer.
The built-in shell, mvdan/sh, hard-blocks a small set of commands at policy level.
Not even --yolo unlocks them:

shutdown · reboot · halt · poweroff · mkfs · init

An attempt returns “command “…” is blocked by shell policy”.
This is insurance against catastrophe, not real isolation.

2.3 Hooks

Pre-hooks add control of your own.
A before hook with a non-zero exit code blocks the tool.
For example, forbid bash when the working directory is your home:

"hooks": {
  "bash": { "before": "[ \"$EONYX_CWD\" = \"$HOME\" ] && exit 1 || exit 0" }
}

There is a whole article on hooks.

3 📋 Summary