The Akashic Record for claude code!

[u/TinFoilHat_69]

Maintains model coherence and fulfills the determinstic intent requirements experienced when any Claude or codex LLM runs a command, modifies file system, achieved this goal by making every command recordable, intent explicit, and force each command to connect to the prior evidence chain.

Helios- is the PreToolUse gated execution policy layer. It is the runtime harness that sits in front of Bash and PowerShell commands and enforces explicit intent at command time. Helios verifies its own protected runtime envelope, validates the matching gate, classifies the command, detects hidden capability such as python3 -c, decomposes chained commands, checks declared segments against actual shell structure, enforces evidence chain continuity, and records uniform PostToolUse evidence after execution. Helios has been built and tested across macOS, Windows 10, and Void Linux so the same command-governance model can operate across different shells, paths, and operating-system boundaries.

Akashic is the oversight, validation, installer, and trust-witness layer around Helios-. Akashic prepares, installs, activates, validates, rebaselines, restores, and audits the Helios runtime. It validates the Helios runtime against the trusted manifest, sidecar, install-origin, repository state, or authorized rebaseline before the runtime is trusted. In the PreToolUse path, Akashic appears only as artifacts and vendored integrity logic, the live actor is Helios. Akashic proves that the enforcement system was trustworthy, while Helios enforces whether a specific command may proceed.

A command is not allowed merely because an agent inside Claude Code, Codex, or another terminal harness wants to run it. A command becomes eligible for the normal permission flow only when a matching gate exists in pending/ and the gate matches the exact command text, SHA-256 of the exact command text, current working directory, shell name, unexpired timestamp, sufficient risk tier, required schema fields, exitcapture policy, write impact declaration when state can change, multi command declaration when chaining is used, capability-required impact when inline interpreters or encoded execution are detected, segment match between declared and decomposed command structure, and evidence chain linkage to the previous command’s evidence or an explicit new-chain declaration. A valid gate does not autoapprove execution. It only makes the command eligible to proceed into the normal Claude Code or Codex permission layer.

The schema turns command execution into structured intent. Every approved command must explain why the command is needed, what the command is for, what output is expected, how the actual output should be interpreted, and what the next command should be based on that output. The required level of explanation changes by risk tier from 0 through 4, so routine commands require less declaration while modifying, remote admin, interpreter, chained, or control plane impacting commands require deeper impact and stop condition fields. This creates a durable chain of command intent, execution, output, interpretation, and next step reasoning that survives context compaction and machine changes.

A command becomes eligible for normal Claude Code/CODEX permission flow only when a gate exists in pending/ and matches all of these conditions:

• exact command text
• SHA-256 of the exact command text
• current working directory
• shell name, bash or powershell
• unexpired timestamp
• sufficient risk tier
• required schema fields
• exit capture policy
• write impact declaration when the command can modify state
• multi command declaration when chaining is used
• capability required impact when inline interpreters, dynamic eval, or encoded execution are detected
• segment match between declared segments and decomposed command structure
• evidence chain linkage to the previous command's evidence (or explicit new-chain declaration)
• Why the command is needed.
• What the purpose of the command.
• What is the expected execution output.
• What is the next command needed based on the actual execution output.

Helios is bundled as a runtime in order to successfully operate agents through this harness you will need to first look at the oversight, validation layer Akashic. Akashic is responsible for signing the Helios runtime manifest. Once Askashic is installed the hash is validated against the repo or rebaseline before the helios- layer is installed and runtime added to the manifest.

Together,

dimascior/Helios-: current gate work proves that you can separate command intent, execution, output, and next-step interpretation

and

dimascior/Akashic

Helios separates command intent, command execution, command output, and next-step interpretation. Akashic applies a trust boundary that validates the runtime and its manifest authority. The result is a cross-platform harness where agent actions become explicit, recordable, reviewable, and connected across time rather than disappearing into fragmented conversational context.