▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄ ▄▄▄ ▄▄▄ ▄▄▄ ▄▄▄ ▄▄▄ ▄▄▄ █ ▄▄▄▄█ █ ▄▄▄ █ █ █▄█ █ █▄ ▄ ▄█ █▄ ▄ ▄█ █ ▄▄▄█▄ █ █ █ █ ▄ ▄ █ █ █ █ ▄█ █▄ █▄▄▄▄▄█ █▄█▄▄▄█ █▄█ █▄█ █▄█ █▄▄ ▄▄█
EONYX is written in Go and builds into a single static binary. Inside is a tidy set of packages built around one central abstraction. Let’s walk through how it is put together — useful both for contributors and for understanding the agent’s behaviour.
Hooks are shell commands that EONYX runs around tool calls: before (before) and after (after). They are a convenient way to bolt on auto-formatting, auditing, checks and guardrails without touching the agent’s code.
An agent that reads and edits code and runs commands must operate within explicit permissions. In EONYX security is several layers: a static gateway, a file sandbox, plan mode and a coarse block on dangerous commands. Let’s go through each of them.
The main way to work with EONYX is the interactive terminal interface (TUI): response streaming, the command palette, pickers and dialogs. Here is everything worth knowing to work fast.
A subagent is a separate instance of the agent that EONYX hands part of the work to. It performs the task in its own context window, with a reduced set of tools, and returns only the result into the main conversation. This keeps the main context clean: the details of the research don’t clutter the dialog. This article covers the task tool, the full list of built-in tools, and how the agent loop works.
Besides the interactive TUI, EONYX can run headless — perform a task and exit. That is what you need for scripts, pipes and CI: predictable output, JSON events and meaningful exit codes.
Features are nice, but it is more interesting to see them at work. A few practical scenarios: how to phrase the task and which EONYX techniques to turn on. The prompts are deliberately plain.
