The coding tool
An agent uses Hania Code through one tool of type Code. Create it from Add tool on the Tools page, point it at a paired machine and a project directory, and assign it to an agent like any other tool.
Configuration
| Field | What it does |
|---|---|
machine_id | The paired machine this tool runs on. Its runner daemon must be connected. |
workdir | The absolute project directory on that machine. All paths resolve under it, and the tool refuses to escape it. |
auto_approve | When on, writes, edits, and commands run without a confirmation card. Leave off to review each change first. |
bash_permissions | Optional ordered rules for shell commands. See permission rules. |
permissions | Optional ordered rules for any action, not just commands. See permission rules. |
hooks | Optional commands to run on the machine around a tool action. See hooks. |
The machine and directory set here are where the tool runs from the console or a channel. From the terminal client, a pasted machine key takes over: coding runs on the machine that key resolves to, in the folder hania was launched from. A terminal user who pastes no machine key falls back to the machine configured here, so an agent used only from the terminal with a machine key can leave these blank - but an agent used anywhere else needs both set, or the tool has nowhere to run.
Approvals
With auto_approve off, every write, edit, and shell command pauses the turn and shows an approval card: a red and green diff for file changes, the command line for commands. You approve, approve with edited arguments, or deny with a reason, and the agent continues from your decision. Reads and searches never prompt.
auto_approve on the tool configuration, not by the assignment's Approval setting. The tool decides per action, so the generic per-tool approval gate does not apply to it, and the editor shows that control disabled on code assignments.
Permission rules
Beyond the single on/off of auto_approve, two optional rule lists give finer control. Rules are ordered and the last matching rule wins, so put broad rules first and exceptions after them. Each rule's action is allow (run without asking), ask (show the approval card), or deny (refuse outright).
bash_permissions matches shell commands only, and wins over the built-in safe-command defaults:
[
{ "pattern": "git push*", "action": "ask" },
{ "pattern": "npm run build", "action": "allow" }
]permissions matches any action. Each rule names the action in permission - bash, edit, write, or apply_patch - and the target in pattern, which matches the command for bash and the file path for the rest:
[
{ "permission": "edit", "pattern": "docs/**", "action": "allow" },
{ "permission": "write", "pattern": "*.env", "action": "deny" }
]Hooks
Hooks run your own commands on the machine around a tool action. PreToolUse hooks run before the action, and one that exits non-zero blocks it. PostToolUse hooks run after, and their output is added to the result the agent sees - a natural place for a linter, so the agent is told about problems in the code it just wrote.
{
"PostToolUse": [
{ "matcher": "edit|write|apply_patch",
"command": "golangci-lint run $HANIA_TOOL_TARGET",
"timeout": 60 }
]
}Each entry has a matcher against the action name, the command to run, and a timeout in seconds. The command receives HANIA_TOOL_ACTION and HANIA_TOOL_TARGET in its environment, so one script can behave differently per action or per file.
Assign it to an agent
Assign the tool from the agent's Tools tab, the same as any other tool. One agent can have coding tools for several machines or several projects; give each configuration a name that says which is which. The agent picks the tool by its name and description when it decides to work on code, so accurate names help it choose correctly.