Claude Code Safety Event: A Log of Every Blocked Action

Can you see how often your AI coding agent was stopped from doing something risky? As of Claude Code version 2.1.307, there is a new way to find out. The changelog lists a claude_code.safety_event record, sent for each tool call that a permission rule, auto mode, a safety check, a hook or the sandbox stopped, prompted or sent back.

In plain terms, the guardrails around the AI can now leave a trail. This article explains what changed, what it means for a team that is not made up only of engineers, and where Atlas stands on it.

What is the Claude Code safety event?

Claude Code is Anthropic's AI coding agent. Before it does something on a computer, such as running a command or editing a file, several safeguards can step in. The changelog entry for version 2.1.307 names them:

• A permission rule. A written rule about what the agent may do, may not do, or must ask about first.
• Auto mode. A mode in which the agent asks for approval less often.
• A safety check. A check that can stop or question an action.
• A hook. A small script a team attaches to Claude Code so it runs at set moments in the agent's work.
• The sandbox. A fenced-off area that limits what a command can reach on the machine.

The new safety event is the record these safeguards now produce. The changelog describes it as an OpenTelemetry event "for each tool call a permission rule, auto mode, a safety check, a hook or the sandbox stopped, prompted or sent back". A "tool call" is one action the agent tries, such as running a command. "Prompted" means the person was asked. "Sent back" means the action was returned to the agent rather than carried out.

The entry sits under version 2.1.307, which was the newest version at the top of the changelog when I read it on 22 October 2026. The changelog entries I saw carry no dates, so I give none.

What changed compared with before?

Without such a record, you could only see a block if you were watching the screen. If the agent ran overnight, or ten engineers ran agents at once, a refusal could scroll past and nobody would know.

Claude Code already sent other kinds of activity records. Its monitoring documentation lists events such as a prompt being submitted, a tool finishing, a permission decision being made, and a plugin being installed or loaded. The safety event is one more kind in that family, aimed at one question: where did a safeguard step in?

It is a record, not a new safeguard. Nothing new is blocked because of it. It makes existing stops visible after the fact.

How do you turn it on?

This is a task for whoever looks after your tooling. Claude Code sends this data using OpenTelemetry, a widely used standard for passing activity data to a monitoring tool. According to the monitoring documentation, you need to:

1. Enable telemetry by setting CLAUDE_CODE_ENABLE_TELEMETRY to 1.
2. Choose where events go with OTEL_LOGS_EXPORTER. The options are otlp, console and none.
3. Set a protocol and an endpoint for the receiving tool. There is no default protocol, so you must set one.

The records go nowhere useful on their own. Someone needs to run, or subscribe to, a place that collects them, such as the logging tool your company already uses.

One caution. The changelog gives a single sentence about this event. In the monitoring documentation I could read, I did not find a section describing the safety event's individual fields. Before you promise anyone a report, such as "stops per week by project", look at a few real records in your own setup and see what they contain.

What does it mean for a team?

For founders and managers

Guardrails are easy to claim and hard to prove. A log lets you ask concrete questions:

• How often was the agent stopped last month?
• Did the stops come mostly from one rule, or from the sandbox?
• Did anything change after we loosened a rule?

If the agent is never stopped, that is also information. Either the work is calm, or your rules are too loose to matter. Without a record you cannot tell which.

For testers and analysts

You can treat guardrails like any other part of the product and test them. Write a rule, try an action it should stop, and check that a record appears. If none does, the rule may not be doing what you think. This turns "we have safety settings" into something you can verify.

For engineers and tech leads

The log helps you tune. A rule that fires constantly on harmless work wastes everyone's time, and people respond by approving things without reading. A rule that never fires may be set up wrongly. Stops that repeat for the same action show where the agent needs a clearer written instruction.

It can also support a review after something goes wrong. If a bad change landed, you can look at what the agent tried, and what was stopped, around that time.

What are the limits?

• It records, it does not explain. A log entry says something was stopped. Deciding whether the stop was right is still a human job.
• It needs setup. Without telemetry switched on and a destination chosen, you get nothing.
• It covers Claude Code only. It tells you nothing about other tools your team may use.
• Details are thin. The only public description I found is the changelog line, so field names and content need checking in practice.
• Think about who can read it. Logs about what an agent did are sensitive. The monitoring documentation says content such as prompts and tool details is off by default and has to be switched on separately. Decide who may see the logs, and what to include, before you collect them.

Does Atlas handle this?

Partly, and only around the edges. Atlas is a software team made of AI engineers, built on Claude Code. It has its own guard rules. It refuses to mark work done until the work is on the main branch, or queued to be merged there, and the product's rules pass. It also never decides production go-lives, spending, deleting data, sending anything outside or dropping scope for you. But nothing in what Atlas says about itself covers gathering Claude Code's own safety events into a screen or a report. So Atlas does not give you a list of "what was stopped, and by which safeguard". If you need that today, the OpenTelemetry route above is the way. You can read more about the team at the Atlas home page.

Conclusion

Version 2.1.307 of Claude Code makes its safeguards observable. Each stop, question or send-back from a permission rule, auto mode, a safety check, a hook or the sandbox can now be written to a log. That will not make an AI agent safer by itself. It does let you check whether your rules do what you meant, and it gives managers and testers something real to look at. If your team already uses Claude Code seriously, ask your engineers to switch it on for one project, read a week of records, and decide what to tighten or loosen from the evidence.