engram-hook-trust
Skill2 starsChanged 3 months agoMITView on GitHub
Safely inspect, back up, and explicitly restore the eight native Engram Codex MCP hook approvals without changing unrelated hooks or approvals.
In this repository11 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .github/copilot-instructions.mdCopilot instructions
- engram-rebuildSkill
- engram-close-sessionSkill
- engram-connectSkill
- engram-new-sessionSkill
- engramSkill
- engram-task-workflowSkill
- engram-wiki-workflowSkill
- orchestrateSkill
- sageSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 8
Use this skill only for the native Codex engram_report_codex_event MCP hooks.
- Very specific: line 14
Run scripts/engram-hook-trust.mjs --help first.
- Distinctive: line 28
Never use a backup to manufacture approval for a changed definition, another Codex root, or any hook outside this eight-event allowlist.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Engram Hook Trust
Use this skill only for the native Codex engram_report_codex_event MCP hooks.
It covers exactly: UserPromptSubmit, PreToolUse, PostToolUse,
PermissionRequest, Stop, Interrupt, SubagentStart, and SubagentStop.
It never manages SessionStart, titles, command hooks, arbitrary servers, or
other approval state.
Run scripts/engram-hook-trust.mjs --help first. The script uses Codex
app-server APIs and does not parse or rewrite TOML.
checkis read-only and reports finite status/reason codes. With--backup, it also reports how many snapshot entries are currently recoverable.backupis read-only against Codex. It creates a new immutable backup of the trusted-and-enabled subset only; it never adds an untrusted event.restorerequires--confirm --backup <file>. It restores only a missing state record whose live canonical key and generated native definition hash exactly match the backup. It skips already trusted/enabled state and rejects existing untrusted/disabled state, changed definitions, unknown status, or root-mismatched state. An absent record reported asuntrustedis eligible only when its unchanged approval was captured in this root's backup.
Never use a backup to manufacture approval for a changed definition, another
Codex root, or any hook outside this eight-event allowlist. Do not run restore
unless the user explicitly requests that specific restore operation.
Show the check result first: deletion alone cannot distinguish Orca's cleanup
from intentional user revocation. Never watch/restore automatically or import
approvals from config.toml.bak. If an approval disappeared before a valid
backup existed, ask the user to review it in Codex /hooks, then make a new
backup. Do not run a provider conversation or event hook to perform these tasks.
Typical invocation requires the native Codex executable, not the codex.cmd
npm shim: node scripts/engram-hook-trust.mjs check --root "$env:CODEX_HOME"
--codex-executable <path-to-codex.exe>. Backups must live under
$env:CODEX_HOME/.engram-hook-trust/.
Resolve the installed native executable and the target root explicitly; do not
mix the ordinary Codex home and Orca home. Run from the skill directory, or use
the absolute script path. Use a new filename for every backup. For example,
after setting task-local $trustScript, $trustRoot, $trustExe, and
$trustBackup to those verified paths:
node $trustScript backup --root $trustRoot --backup $trustBackup --codex-executable $trustExe
node $trustScript check --root $trustRoot --backup $trustBackup --codex-executable $trustExe
# Only after the user requests this specific recovery:
node $trustScript restore --root $trustRoot --backup $trustBackup --codex-executable $trustExe --confirmReport partial backup counts honestly. A backup with two records cannot restore
the other six hooks. A failed post-write verification may mean a write occurred;
inspect with check and stop instead of retrying or rolling back approvals.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

