React to safety checks
Safety checks belong to the client. They compare what automation intended with what Minecraft did, keep a history, notify the player, and apply the player's chosen response. A script can observe that result. It cannot disable a check, change a policy, or make the client ignore evidence.
"requestedCapabilities": ["safety.read"]
Race an alert with work
safety.alert is an ordinary event subscription, so it can take part in the
same hexis.select as actions and other event sources:
local alerts = hexis.events.subscribe({type = "safety.alert"})
local outcome = hexis.select({candidates = {work, alerts}, timeout = 30})
if outcome.kind == "event" and outcome.event.type == "safety.alert" then
local alert = outcome.event.data
-- alert.kind, alert.severity, alert.action, alert.score
park_safely()
end
The stream has no filter. The client has already decided that the observation belongs in its safety history, and every subscriber sees the same decision.
Each event's data contains:
| Field | Meaning |
|---|---|
kind | The check that observed the anomaly |
severity | The weight of this observation before evidence decays |
action | log, alert, stop, or leave |
score | The accumulated, decaying score for this check |
evidence | Check-specific facts used to explain the decision |
artificial | True when the player used the check's self test |
The action is not a request to the script. Hexis applies it independently. A
stop ends the run through normal teardown; a leave stops it and asks the
break schedule to apply the player's server policy.
Read the current state
Use hexis.safety.observe() when a stream is unnecessary:
local safety = hexis.safety.observe()
-- safety.last_alert is absent until this client session has one.
-- safety.recent_count is the number of persisted history rows, capped at 200.
Observation also costs safety.read. It is intentionally read-only: recovery
stays with the player and the client's policy rather than the code being held.
Ask for reduced rendering
A work script can declare that it is safe to reduce visual detail while it is actually engaged:
"performance": {"reduce_rendering": true}
This is an opt in, not a setting. Nothing changes unless the player also turns on Light performance mode. An armed passive script changes nothing while it is waiting. When an opted-in script starts work, Light caps the frame rate at 20, reduces particles and visual effects, and suppresses fog and weather. It never lowers render distance because scripts and pathfinding still need loaded chunks.
The client keeps these changes in memory and restores only values it still owns when work stops, the world changes, authority is lost, or the client shuts down. A visual setting the player changes while Light is active is left alone.