Changes without asking
Halon asks before a change by how much the change risks, not by which tool makes it. A safe change runs at once and shows up in the chat with Undo, a risky change asks you first, and your admins can list risky changes Halon may make without asking.
What asks and what does not
Section titled “What asks and what does not”In your chat with Halon, on the dashboard or in Slack:
| The change | What happens |
|---|---|
| A read, such as logs, metrics or a pull request | Never asks |
| A safe change, such as assigning someone to an issue or restarting a service that runs more than one copy | Runs without asking, then shows in the chat, with Undo where there is a fixed way to put it back |
| A risky change, such as a rollback, a merge or a scale down | Asks you first, unless your workspace’s list allows it before Halon has read anything from outside in the chat, or you allowed it for the rest of the chat |
| A change an approval rule covers | Asks the approvers once, or you when you may approve it yourself |
| A change to permissions, API keys, approvals or webhooks, or a tool that changes who can reach something or sets a secret | Always asks a person, whatever the setting or the list says |
Halon still needs your permission for every change. A safe change, or one on the list, only skips the question. It never lets Halon do something you could not do yourself.
Safe changes
Section titled “Safe changes”A safe change is harmless or easy to put back, and touches no data, access, money or where your traffic goes. These count as safe:
| Where | Safe changes |
|---|---|
| GitHub | Assigning people to an issue and asking for reviews. Until Halon has read anything from outside in the chat, also commenting on an issue or a pull request, replying to a review comment, adding or taking off labels and running a repository’s tests in Firefight’s sandbox |
| GitLab | Running a project’s tests in Firefight’s sandbox, until Halon has read anything from outside in the chat |
| Bitbucket | Running a repository’s tests in Firefight’s sandbox, until Halon has read anything from outside in the chat |
| Azure DevOps | Running a repository’s tests in Firefight’s sandbox, until Halon has read anything from outside in the chat |
| Render | Turning a service’s autodeploy off |
| Trigger.dev | Marking an error group resolved or unresolved, and ignoring one until Halon has read anything from outside in the chat |
| Opsgenie | Adding a note to an alert, until Halon has read anything from outside in the chat |
| Anything on the resource map | Restarting a service that runs more than one copy, and scaling a service up to at most double its current count and no more than 10 extra, without changing its plan |
A comment, a note, a label and running the tests count as safe only until Halon has read anything from outside in that chat, since outside text could steer what they say or do. The tests run in a sandbox that can reach the internet. After that they ask. Running CI again always asks, since a run can deploy.
Everything else that changes something is risky. Scaling down, deleting, deploying, rolling back, merging, closing, writing to a database and changing secrets all ask. So does a restart of a database, a whole machine or a service running a single copy, and a restart asked for through a provider’s own restart tool rather than Halon’s. When Firefight cannot read a service’s current count, a restart or a scale asks you. A tool on an MCP server you connected is risky unless Firefight knows exactly what it does.
Turning safe changes off
Section titled “Turning safe changes off”Safe changes run without asking by default. To have Halon ask before each one, go to Settings → Workspace, turn off Halon makes safe changes without asking in the Halon section, then click Save changes. Turning it off changes nothing else, and risky changes ask either way.
What you see after a safe change
Section titled “What you see after a safe change”Halon says what it changed in its reply. The chat also shows a card for the change with its name, where it ran and why Halon did not ask, such as “Halon made it without asking, since it is a safe change.” In a Slack thread, the same line is posted in the thread.
Some safe changes have one fixed way to put them back, and their card and Slack message offer Undo now:
| The change | Undo now |
|---|---|
| A comment, or a reply to a review comment, on GitHub | Deletes that comment |
| Labels added to or taken off an issue or a pull request | Takes them off or puts them back |
| People assigned to an issue | Takes them off it |
| Scaling a service up | Scales it back to the count it had before |
| Turning a Render service’s autodeploy off | Puts its autodeploy back as it was |
| Resolving or ignoring a Trigger.dev error group that was unresolved | Marks it unresolved again |
Undo now asks you first, then does exactly that, on the same connection, as the person who asked for the change, and the card says how it went. An approval rule can still hold it. Undo now does not expire. Any other change, such as running the tests or restarting a service, says there is no Undo for it.
What Halon may do without asking
Section titled “What Halon may do without asking”Your admins can list risky changes Halon may make without asking in anyone’s chat, such as “Roll back deploys in Staging”. It saves approving the same kind of change in every chat. Allow for the rest of this chat on a question still works for one chat.
Each entry names one of these:
- A change to anything on the resource map, rolling back deploys, restarting services and databases, or scaling services. You can keep it to one connection.
- One connection’s tool, such as merging a pull request on GitHub.
You can keep an entry to one environment, such as Staging. A call that names no environment is not covered by an entry kept to one.
Some changes can never be on the list: changes to who can reach something or to a secret, a tool that can call any part of a provider’s API, a tool that writes rows to a database (each write is counted and shown to you first) and a tool on an MCP server you connected.
Adding an entry
Section titled “Adding an entry”- Go to Settings → Workspace and find Halon may do these without asking.
- Click Add.
- Under Halon may, pick the change.
- For a change to anything on the map, pick a connection under On, or leave Any connection.
- Under In, pick an environment, or leave Every environment.
- Click Add.
Each entry has a switch to turn it off and on, and a menu to edit or delete it. Once Halon has made a change under an entry, it can no longer be deleted, so it stays in the record, and you turn it off instead. Managing the list needs the permission to manage permissions.
When Halon makes a change under an entry, the chat shows it the same way as a safe change, naming the entry, with Undo now where there is a fixed way to put it back.
Until Halon reads something from outside
Section titled “Until Halon reads something from outside”The list covers changes until Halon has read anything from outside in that chat, the same as Allow for the rest of this chat. That includes the answer of any tool, Firefight’s own included, a file someone attached, an answer Firefight passes back to Halon, such as one from a call an approver ran, a memory nobody has confirmed, the incident’s name, which can come from an alert’s title, and what its investigations found. After that, Halon asks you on its card as usual, and the card says the change is on the list and why it asks anyway. The card lists what Halon read under Details.
In a chat about an incident, such as one in its channel, the incident’s name is there from the first message. So the list never covers a change in that chat, and a comment, a note, a label or running the tests asks from the start. The other safe changes, such as assigning someone or restarting a service that runs more than one copy, run without asking whatever Halon has read.
Approval rules still apply
Section titled “Approval rules still apply”Neither safe changes nor the list ever stand in for an approval rule. When a rule covers a change and you may approve it yourself, Halon asks you on its card, and approving is your approval. When the rule needs someone else, Halon does not ask you first. The request goes straight to the approvers, and the chat shows it waiting for them. Nobody is asked twice for the same change.
A change to rows in a database works the same way. When a rule needs someone else, the approvers’ request shows how many rows the change touches and a few of them, as your card would have, on the Approvals page, in Slack and over MCP. When Halon read text from outside Firefight before the change, the approvers’ request carries the same warning your card would have. A change to who can reach something or to a secret still asks you on your card as well as its approvers.
When you press Approve on the card for running a runbook, any of its steps an approval rule would ask you about runs on that same yes. Allowing runbooks for the rest of the chat does not count. A step that needs someone else’s approval still asks them, and a change to who can reach something or to a secret still waits for an admin to approve it.
A change to who can reach something or to a secret, such as setting a GitHub Actions secret or adding someone to a status page, always asks a person. When a workflow step or a token makes one, it waits for an admin to approve it, whatever permissions allow. So does any change through a tool that can call any part of a provider’s API, since it could change access or a secret. Reading through such a tool, and a restart, scale or rollback Firefight makes through it, work as before. A command Halon runs in its sandbox never makes one. Halon calls the tool itself instead, so you are asked about that change on its own.
When nobody is around
Section titled “When nobody is around”The list applies in chats, where someone asked Halon for something. When an alert starts Halon at night and nobody is there, it acts only under the unattended rules described in Halon on call, each of which checks a fresh reading first.
Everything stays on the record
Section titled “Everything stays on the record”Every change Halon makes without asking is in Gateway → Activity, with why it ran without asking under the action, such as “Made without asking because it is a safe change.” or the entry that allowed it.
Agents and tokens
Section titled “Agents and tokens”Safe changes and the list apply only in a person’s own chat with Halon. When an agent asks Halon over MCP with ask_halon, Halon asks before every change. An agent or a token calling a tool directly holds only what it was granted, and approval rules still hold its calls.
Over the API, GET /api/v1/allowances lists the entries and the MCP server’s list_allowances does the same. Adding, changing and deleting an entry, and turning safe changes on or off, is refused with a token. Only a person in Firefight decides what Halon does without asking.