Hooks

Hooks execute configured actions on agent lifecycle events. The EvoX Extensions Hooks page inspects, diagnoses, and rescans configuration to expose provenance and shell risks. It is not a hook editor or a runtime hot-reload interface.

Inspect the source

Open Extensions > Hooks and inspect events, matchers, and scope. The page reads Claude Code-style lifecycle configuration used by the desktop, including user, project, and administrator-managed scopes.

Entries expose events, matchers, scopes, parse status, and shell risk. Displayed command text is bounded and redacted; it does not replace inspection of the original configuration and scripts.

Decide whether a hook fits

Hooks suit bounded checks or records triggered by explicit events. Actions requiring human judgment, external writes, publishing, or spending retain their separate authorization and validation.

Before configuring an action, establish:

• Its lifecycle event, such as PreToolUse, PostToolUse, UserPromptSubmit, or Stop.
• Which calls its matcher covers and whether it unintentionally matches every tool.
• Input, write locations, and network destinations.
• The effect of timeouts, errors, and duplicate triggers on subsequent work.
• Whether logs contain prompts, file contents, or credentials.

These hooks have shell execution consequences. Appearing in a configuration list does not make an unfamiliar command trustworthy.

Example: syntax-check after a file edit

This is a project Hook configuration structure. Place it in the owning project configuration while preserving other settings. Replace the command's executable and target file with actual absolute paths:

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{
        "type": "command",
        "command": "\"/absolute/path/to/node\" --check \"/absolute/path/to/project/src/example.mjs\""
      }]
    }]
  }
}

The example checks a fixed file's JavaScript syntax after a matching write/edit event. It does not dynamically check each edited file or execute the module. Quote paths with spaces for the chosen shell. Run the command manually in the target environment before using it as a Hook to establish file and runtime availability.

Save and rescan, then inspect PostToolUse, Write|Edit, source, and command. Restart or load configuration through the agent's lifecycle, perform one test edit, and inspect actual handler output. An entry in the scan proves discovery only.

Remove the example after testing and reload the owning agent so later edits do not keep checking the demonstration file.

Verify disk and runtime separately

The configuration owner performs edits; the Hooks page does not write configuration files. Preserve the original, inspect format and scripts, then save to the correct scope.

Rescan reads disk again and updates discovered entries and parse diagnostics. Rescanning does not reload the running agent's hook table. Follow the hosting agent's loading or restart procedure, then trigger a bounded event to verify behavior.

Do not treat /hooks reload as an implemented runtime reload interface. Saving, successful scanning, and effective execution are separate results.

Diagnose and disable

For parse failures, inspect the failed scope instead of treating missing entries as proof no hook exists. If rescan fails, inspect the last successful scan time; the previous list does not prove the new configuration was read.

Disable a hook in its actual source and verify through the runtime loading procedure. Stopping a hook does not undo files, network actions, or external authorization it already created. Restore using preserved configuration and task records.