@jaguilar87/gaia 5.0.7 → 5.0.8

package/dist/gaia-ops/hooks/modules/tools/bash_validator.py

@@ -90,6 +90,11 @@ class BashValidationResult:
     # plain error string (exit 2).  Used for structured block responses that
     # should correct the agent rather than terminate execution.
     block_response: Optional[Dict[str, Any]] = None
+    # When a T3 command is allowed because it matched (and consumed) an active
+    # grant, this carries the approval_id of that grant. The adapter stashes it
+    # in HookState so PostToolUse can append an EXECUTED/FAILED event to the
+    # approval_events chain for this approval. None for non-T3 / no-grant paths.
+    consumed_approval_id: Optional[str] = None
 
     def __post_init__(self):
         if self.suggestions is None:
@@ -667,6 +672,7 @@ class BashValidator:
                     allowed=True,
                     tier=SecurityTier.T3_BLOCKED,
                     reason="Command-set grant matched",
+                    consumed_approval_id=cs_approval_id,
                 )
 
             # DB-primary + filesystem-fallback grant check.
@@ -720,6 +726,7 @@ class BashValidator:
                         allowed=True,
                         tier=SecurityTier.T3_BLOCKED,
                         reason="Grant confirmed",
+                        consumed_approval_id=db_approval_id,
                     )
                 else:
                     # Filesystem grant exists, not yet confirmed -- GAIA approved,
@@ -733,6 +740,7 @@ class BashValidator:
                         allowed=True,
                         tier=SecurityTier.T3_BLOCKED,
                         reason="Grant active, pending confirmation",
+                        consumed_approval_id=db_approval_id,
                     )
             else:
                 # Converge on the single T3 decision point.  When there is an
@@ -808,6 +816,7 @@ class BashValidator:
                             allowed=True,
                             tier=SecurityTier.T3_BLOCKED,
                             reason="Command-set grant matched",
+                            consumed_approval_id=cs_approval_id,
                         )
 
                     grant = check_approval_grant(command, session_id=session_id)
@@ -859,6 +868,7 @@ class BashValidator:
                                 allowed=True,
                                 tier=SecurityTier.T3_BLOCKED,
                                 reason="Grant confirmed",
+                                consumed_approval_id=db_approval_id,
                             )
                         else:
                             logger.info(
@@ -870,6 +880,7 @@ class BashValidator:
                                 allowed=True,
                                 tier=SecurityTier.T3_BLOCKED,
                                 reason="Grant active, pending confirmation",
+                                consumed_approval_id=db_approval_id,
                             )
 
                     # No grant matched -- converge on the single T3 decision
@@ -939,10 +950,18 @@ class BashValidator:
             key=lambda t: tier_order.index(t.value),
         )
 
+        # Propagate the consumed approval_id from whichever component matched a
+        # grant, so PostToolUse can append EXECUTED/FAILED for that approval.
+        consumed_approval_id = next(
+            (r.consumed_approval_id for r in component_results if r.consumed_approval_id),
+            None,
+        )
+
         return BashValidationResult(
             allowed=True,
             tier=highest_tier,
             reason=f"All {len(components)} components validated",
+            consumed_approval_id=consumed_approval_id,
         )
 
     def _phase4_check_composition(

package/dist/gaia-ops/skills/agent-approval-protocol/SKILL.md

@@ -21,10 +21,18 @@ the hash chain, grant activation, reading a granted approval from Python -- see
 
 ## approval_id format
 
+For a **singular** T3 approval (the hook-block path),
 `store._generate_approval_id()` returns `P-{uuid4().hex}` (e.g.
-`P-b1bdfbb0b9474bf5b3f86b1f6a213f7a`). The `P-` prefix is mandatory: without it
-the PostToolUse hook cannot do targeted grant activation. The first 8 hex chars
-after `P-` are the nonce prefix shown in option labels: `[P-b1bdfbb0]`.
+`P-b1bdfbb0b9474bf5b3f86b1f6a213f7a`) -- a random, unique id the subagent relays
+verbatim. For a **plan-first `COMMAND_SET`** the id is instead **content-derived**
+by `store.derive_command_set_id()`: `P-<first 32 hex of
+sha256(canonical(command strings))>`. The two share the `P-` prefix and 32-hex
+length but differ in origin -- the command_set id is deterministic so the
+orchestrator reproduces it from the command_set (via `gaia approvals derive-id`)
+with no DB search; the singular id is random because the subagent relays it
+directly. The `P-` prefix is mandatory in both cases: without it the PostToolUse
+hook cannot do targeted grant activation. The first 8 hex chars after `P-` are
+the nonce prefix shown in option labels: `[P-b1bdfbb0]`.
 
 ## APPROVAL_REQUEST contract shape
 
@@ -55,8 +63,11 @@ becomes `rollback` in the contract; `commands` (`[exact_content]`) and
 }
 ```
 
-There is no `batch_scope` field: the `verb_family` grant was removed, so each
-blocked command gets its own single-use grant. See
+There is no `batch_scope` field: the `verb_family` grant was removed. For a
+single blocked command, each gets its own single-use `SCOPE_SEMANTIC_SIGNATURE`
+grant. For a batch of >= 2 T3 commands known up-front, emit a `command_set`
+list and **no** `approval_id` -- the SubagentStop intake mints a single
+`COMMAND_SET` grant (one consent covers all). See
 `Skill('orchestrator-present-approval')` for the orchestrator side.
 
 ## Status vocabularies -- distinct columns, opposite casing, never collapse
@@ -69,8 +80,8 @@ blocked command gets its own single-use grant. See
 ## Event chain
 
 The `approval_events.event_type` CHECK admits nine values: `REQUESTED` `SHOWN`
-`APPROVED` `REJECTED` `EXECUTED` `FAILED` `NOOP` `REVOKED` `REVERTED`. Only these
-are written by production code today:
+`APPROVED` `REJECTED` `EXECUTED` `FAILED` `NOOP` `REVOKED` `REVERTED`. These are
+written by production code today:
 
 | Event | Who writes it | When |
 |-------|--------------|------|
@@ -78,11 +89,16 @@ are written by production code today:
 | `SHOWN` | ElicitationResult hook via `activate_db_pending_by_prefix()` | User selects an Approve `[P-xxx]` label |
 | `APPROVED` | ElicitationResult hook (same call as `SHOWN`) | Immediately after `SHOWN` |
 | `REJECTED` / `REVOKED` | `gaia approvals` CLI via `store.reject()` / `store.revoke()` | User rejects or admin cancels |
-
-`EXECUTED` `FAILED` `NOOP` `REVERTED` are valid in the CHECK and are *read* by
-`store.get_executed_payload()` and `revert.py`, but no production hook *writes*
-them today -- treat them as a designed extension point, not a live invariant. Do
-not assume an `EXECUTED` event exists after a command runs.
+| `EXECUTED` / `FAILED` | PostToolUse adapter (`_record_t3_outcome_event`) via `store.record_event()` | An approved T3 command runs under a consumed grant -- `EXECUTED` on clean exit, `FAILED` otherwise |
+
+The PostToolUse path closes the audit cycle: PreToolUse stashes the consumed
+grant's `approval_id` in `HookState`, and PostToolUse appends `EXECUTED` or
+`FAILED` for that approval, continuing the hash chain through `record_event()`.
+`store.get_executed_payload()` and `gaia approvals replay` read the `EXECUTED`
+payload to re-present the commands that ran. `NOOP` and `REVERTED` remain valid
+in the CHECK but are **inert** -- no production code writes them (the revert
+feature was removed). Do not assume an `EXECUTED` event exists for an approval
+whose command never ran, or that ran through the redirect-sanitized path.
 
 ## Key invariants
 

package/dist/gaia-ops/skills/agent-approval-protocol/reference.md

@@ -27,9 +27,11 @@ Each event links to the previous via `prev_hash` -> `this_hash`
 Because `approval_events` is append-only (UPDATE/DELETE blocked by the
 `bu_approval_events_immutable` and `bd_approval_events_immutable` triggers),
 `this_hash` is computed in the application layer before INSERT, inside
-`chain.insert_event()` -- not by a DB trigger. `REVERTED` events, when written,
-carry the original `event_id` in `metadata_json` per the revert design (D14);
-see `gaia/approvals/revert.py`.
+`chain.insert_event()` -- not by a DB trigger. `EXECUTED` / `FAILED` events,
+appended by the PostToolUse adapter through `store.record_event()` after an
+approved T3 command runs, extend the same chain. `REVERTED` remains a valid
+CHECK value but is **inert** -- the revert feature was removed, so no code
+writes it.
 
 ## Grant activation walk-through
 

package/dist/gaia-ops/skills/agent-protocol/examples.md

@@ -330,4 +330,15 @@ The agent discovered a project fact a section it owns did not yet hold, and writ
 
 ## Notes on multi-command APPROVAL_REQUEST sweeps
 
-There is no batch/multi-use grant in the current code: the legacy `verb_family` grant was removed (`hooks/modules/security/approval_grants.py`) and its `COMMAND_SET` replacement has no production activation path yet. Do **not** emit a `batch_scope` field -- it is ignored. When one intent expands into many T3 commands, each blocked command produces its own single-use approval; emit one `APPROVAL_REQUEST` per blocked command (shape identical to example 4 above) and let the user approve each.
+**Just-in-time (unknown batch):** when T3 commands appear one at a time as the
+agent works, each blocked command produces its own `APPROVAL_REQUEST` with an
+`approval_id` (shape identical to example 4 above). Do not emit `batch_scope`
+-- it is ignored.
+
+**Plan-first (known batch):** when the agent knows >= 2 T3 commands up-front,
+emit ONE `APPROVAL_REQUEST` carrying a `command_set` list of `{command,
+rationale}` items and **no** `approval_id`. The SubagentStop intake
+(`handoff_persister._intake_command_set_pending`) mints a single `COMMAND_SET`
+approval; the orchestrator presents it as one consent covering all N commands.
+Each command then runs on its own retry, byte-for-byte matched and consumed
+individually.

package/dist/gaia-ops/skills/orchestrator-present-approval/SKILL.md

@@ -39,7 +39,13 @@ So before AskUserQuestion, two checks against the DB, in order:
 1. **The approval exists, is fresh, and is from the current session.** Query `gaia approvals pending --session "$CLAUDE_SESSION_ID"` (or `--json` for parsing). The reported `approval_id` MUST appear in that result. If it appears only under `--all-sessions` but not the current session, it is leakage from another session (a test session such as `e2e-sim`, a prior run) -- **do not present**. If it does not appear at all, it does not exist or was already consumed/rejected -- **do not present**. Freshness is the `created_at` of the pending row plus its presence as still-`pending`; an id the agent reports that is not currently pending in *this* session is not a fresh block, whatever the agent says.
 2. **The payload is untampered.** Call `verify_fingerprint(approval_id, payload_json, con) -> bool` from `gaia/approvals/chain.py`. It raises `ChainTamperError` if the payload was modified between subagent emission and your relay (security boundary, do not present), and `ValueError` if no REQUESTED event exists for this `approval_id`. Either case: **do not present**, report the failure, stop.
 
-**For a `command_set` (plan-first batch) the agent does not know the id at all.** The hook mints the `approval_id` at SubagentStop (`_intake_command_set_pending` -- see Rule 3); the subagent emits the `command_set` with **no** `approval_id`. So you do not have an agent-reported id to trust even if you wanted to -- you ALWAYS recover the freshly minted id from `gaia approvals pending` for the current session. This is the general shape made unavoidable: the DB mints, the orchestrator recovers, the agent never owns the id.
+**For a `command_set` (plan-first batch) the agent does not know the id at all -- so you DERIVE it deterministically, you do not search the DB.** The hook mints the `approval_id` at SubagentStop (`_intake_command_set_pending` -- see Rule 3) from the **content** of the command_set, not from a uuid4. The id is `P-<first 32 hex of sha256(canonical(command list))>` (`derive_command_set_id` in `gaia/approvals/store.py`). Because it is content-derived, you reproduce the EXACT minted id from the `command_set` you already hold in the contract -- with **no `gaia approvals pending --session` search**. Run:
+
+```
+gaia approvals derive-id --commands-json '<the command_set from the contract>'
+```
+
+It applies the SAME mutative filter the intake used and prints the `P-...` id (the same function `derive_command_set_id` the hook minted with). This closes the cross-session miss: the SubagentStop output never reaches the parent (Claude Code issue #5812), so a random id could not be recovered across sessions -- a content-derived one needs no recovery at all. Having derived the id, run Step 0's existence/fingerprint checks against it exactly as for a singular id (the row is now findable by that exact id). The shape: the DB mints content-derived, the orchestrator re-derives, the agent never owns the id and no search is needed.
 
 ## Mandatory presentation -- 5 labeled fields + nonce-suffixed label
 
@@ -121,4 +127,4 @@ wording, see `reference.md` -> "GOOD vs BAD Examples", "Option Label Patterns",
 | "The same command emitted a new approval_id" | Grants are single-use and consumed on the first retry. A second run is a new APPROVAL_REQUEST -- approve again. |
 | "I'll set batch_scope to approve many at once" | `batch_scope` is ignored -- but a real batch path exists: a plan-first `command_set` (>= 2 items, no `approval_id`) is intaken into ONE pending `COMMAND_SET`. Present that single approval (N commands shown, one `[P-...]` nonce, one consent), not N separate approvals. |
 | "I can paraphrase a field before relaying" | The fingerprint covers all 7 sealed fields; any modification raises `ChainTamperError` in Step 0 and the presentation is refused. |
-| **"The agent reported an `approval_id`, so it's a real fresh block"** -- trusting a nonce relayed by the subagent | The agent's reported id is an unverified pointer, not a fact. It can be stale or belong to another session -- subagents have presented a STALE nonce from a test session (`e2e-sim`) as if it were a fresh block. Resolve every reported id against `gaia approvals pending --session "$CLAUDE_SESSION_ID"` (Step 0): it must be currently pending in *this* session. Visible only under `--all-sessions`, or absent entirely, means do not present. For `command_set` the hook mints the id and the agent never has one -- you always recover it from the DB. |
+| **"The agent reported an `approval_id`, so it's a real fresh block"** -- trusting a nonce relayed by the subagent | The agent's reported id is an unverified pointer, not a fact. It can be stale or belong to another session -- subagents have presented a STALE nonce from a test session (`e2e-sim`) as if it were a fresh block. Resolve every reported id against `gaia approvals pending --session "$CLAUDE_SESSION_ID"` (Step 0): it must be currently pending in *this* session. Visible only under `--all-sessions`, or absent entirely, means do not present. For `command_set` the hook mints the id and the agent never has one -- you **derive** it deterministically from the command_set via `gaia approvals derive-id` (content-derived, no DB search), then run the same existence/fingerprint checks. |

package/dist/gaia-ops/skills/orchestrator-present-approval/template.md

@@ -26,16 +26,17 @@ AskUserQuestion(
 Where `approval_id_prefix8` is the first 8 characters of the `approval_id`
 field from the subagent's `approval_request` (after the `P-` prefix).
 
-## No batch template
-
-There is no batch/multi-use approval in the current code. The `verb_family` grant
-was removed (see the module docstring of
-`hooks/modules/security/approval_grants.py`) and the `COMMAND_SET` replacement
-has no production activation path (`create_command_set_grant` has no production
-caller). The word "batch" in a label and a `batch_scope` field are both ignored.
-For a sweep of N commands, present each command with its own single-command
-approval (the template above), once per `approval_id`. See `reference.md` ->
-"On batch intents".
+## Batch template (COMMAND_SET)
+
+When the subagent emits a plan-first `APPROVAL_REQUEST` with a `command_set`
+of >= 2 `{command, rationale}` items and **no** `approval_id`, the
+SubagentStop intake mints ONE pending `COMMAND_SET` approval. Present it as
+a single approval: list all N commands in the question body, one Approve
+label with one `[P-{nonce8}]` suffix. See `reference.md` -> "On batch
+intents" for the full layout.
+
+A `batch_scope` field and the word "batch" in an option label are both
+ignored -- the signal is the presence of `command_set` in the contract.
 
 ## Field Extraction Reference
 

package/dist/gaia-ops/skills/subagent-request-approval/SKILL.md

@@ -99,6 +99,17 @@ with one `approval_id` -- so a batch of N commands is **one consent, N
 commands**, not N approvals. A set of `<= 1` item is not a batch: it does not
 mint a COMMAND_SET (use the normal singular block path for a single command).
 
+You still emit the `command_set` with **no `approval_id`** -- nothing changes on
+your side. What changed underneath: the minted `approval_id` is now
+**content-derived** from the command_set
+(`derive_command_set_id` -> `P-<first 32 hex of sha256(canonical commands)>`),
+not a random uuid4. You do not compute or emit it (you cannot hash reliably, and
+you have nothing to attempt yet); the value is purely internal. The reason it
+matters: the orchestrator reproduces that exact id from the `command_set` you
+emitted (via `gaia approvals derive-id`), with no DB search and no cross-session
+miss. Your contract stays the same -- `command_set` of `{command, rationale}`
+items, no `approval_id`.
+
 On the user's approval, that one pending activates into a single `COMMAND_SET`
 grant (60-minute TTL); each item is then consumed byte-for-byte on its own
 retry, with replay protection, until the whole set is `CONSUMED`. See

package/dist/gaia-ops/skills/subagent-request-approval/reference.md

@@ -94,6 +94,22 @@ COMMAND_SET is ever minted for one command). The intake runs independently of
 the audit handoff-row write, so a batch consent is never lost to an unrelated
 DB failure.
 
+**The COMMAND_SET `approval_id` is content-derived, not uuid4.** Unlike the
+singular hook-block path (which mints `P-{uuid4hex}`), the intake derives the id
+from the command_set content via `gaia.approvals.store.derive_command_set_id()`:
+`P-<first 32 hex of sha256(canonical(post-filter command strings))>`. It then
+passes that id to `insert_requested(..., approval_id=...)` as the pending row id.
+The point is reproducibility without a DB lookup: the orchestrator holds the
+same `command_set` (you emitted it in the contract) and reproduces the EXACT id
+with `gaia approvals derive-id`, which applies the same mutative filter and the
+same canonicalization (`chain.canonical_payload`). This closes the cross-session
+miss -- a uuid4 minted at SubagentStop could not be recovered by the parent
+(Claude Code #5812), but a content-derived id needs no recovery. The id is
+**order-sensitive** (the consume side matches positionally) and **content-only**
+(rationale/session/agent are not folded in, so both sides agree from the command
+list alone). Idempotency follows the existing fingerprint dedup: two identical
+command sets map to one id.
+
 **Envelope shape.** The sealed_payload the intake writes carries a `command_set`
 key holding the verbatim list of `{command, rationale}` items, and `commands`
 listing every command string in the set:
@@ -142,9 +158,11 @@ orchestrator which path:
   validates the fingerprint and activates the single-use semantic grant on user
   approval.
 - **Without `approval_id`, with a `command_set` of >= 2 items** -- plan-first
-  batch. The SubagentStop intake processor mints ONE pending `COMMAND_SET` and
-  the orchestrator presents that single approval (N commands, one nonce) before
-  any execution. See "Batch / COMMAND_SET -- wired" above.
+  batch. The SubagentStop intake processor mints ONE pending `COMMAND_SET` with a
+  **content-derived** id (`derive_command_set_id`), and the orchestrator
+  reproduces that exact id from the command_set via `gaia approvals derive-id`
+  (no DB search) before presenting the single approval (N commands, one nonce).
+  See "Batch / COMMAND_SET -- wired" above.
 - **Without `approval_id` and without a multi-item `command_set`** -- plan-first
   single (you are presenting one T3 plan before attempting); the orchestrator
   gates on user consent before any execution.

package/dist/gaia-security/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "gaia-security",
-  "version": "5.0.7",
+  "version": "5.0.8",
   "description": "Keeps you in the loop only when it matters. Gaia Security analyzes every command and classifies it into risk tiers: read-only queries run freely, simulations and validations pass through, and state-changing operations (create, delete, apply, push) pause for your explicit approval before executing. Irreversible commands like dropping databases or deleting cloud infrastructure are permanently blocked.",
   "author": {
     "name": "jaguilar87",

package/dist/gaia-security/hooks/adapters/claude_code.py

@@ -603,13 +603,18 @@ class ClaudeCodeAdapter(HookAdapter):
                 exit_code=2,
             )
 
-        # Save state for post-hook
+        # Save state for post-hook. When the command was allowed by consuming a
+        # T3 approval grant, carry that approval_id forward so PostToolUse can
+        # append an EXECUTED/FAILED event to the approval_events chain (the grant
+        # is consumed here at PreToolUse and flips to CONSUMED, so PostToolUse
+        # cannot re-discover it via check_approval_grant).
         effective_command = result.modified_input.get("command", command) if result.modified_input else command
         state = create_pre_hook_state(
             tool_name=tool_name,
             command=effective_command,
             tier=str(result.tier),
             allowed=True,
+            consumed_approval_id=result.consumed_approval_id,
         )
         save_hook_state(state)
 
@@ -1003,6 +1008,26 @@ class ClaudeCodeAdapter(HookAdapter):
                             "T3 grant confirmed (will be consumed at SubagentStop): %s", command[:80],
                         )
 
+            # Close the audit-log cycle for an APPROVED T3 command that just ran.
+            # PreToolUse stashed the consumed grant's approval_id in HookState
+            # when it matched (and consumed) the grant; append EXECUTED on a clean
+            # exit, FAILED otherwise. This continues the approval_events hash chain
+            # via the canonical store.record_event() helper -- the only authorized
+            # writer for the chain (it routes through chain.insert_event(), which
+            # links prev_hash -> this_hash before INSERT).
+            if tool_name == "Bash":
+                consumed_approval_id = (
+                    pre_state.metadata.get("consumed_approval_id") if pre_state else None
+                )
+                if consumed_approval_id:
+                    self._record_t3_outcome_event(
+                        consumed_approval_id,
+                        command=parameters.get("command", ""),
+                        success=success,
+                        exit_code=tool_result_data.exit_code,
+                        session_id=hook_data.get("session_id", ""),
+                    )
+
             events = detect_critical_event(tool_name, parameters, output, success)
             if events:
                 writer = SessionContextWriter()
@@ -1031,6 +1056,53 @@ class ClaudeCodeAdapter(HookAdapter):
 
         return HookResponse(output={}, exit_code=0)
 
+    def _record_t3_outcome_event(
+        self,
+        approval_id: str,
+        *,
+        command: str,
+        success: bool,
+        exit_code: int,
+        session_id: str = "",
+    ) -> None:
+        """Append an EXECUTED or FAILED event for an approved T3 command.
+
+        Closes the audit-log cycle: once a command runs under a consumed grant,
+        the approval_events chain records whether it succeeded (EXECUTED) or
+        failed (FAILED). Writes through gaia.approvals.store.record_event(), the
+        canonical chain writer -- never a raw INSERT -- so prev_hash -> this_hash
+        linkage is preserved and validate_chain() stays intact end to end.
+
+        Best-effort and non-fatal: the approval store lives in gaia.db and may be
+        unavailable in some hook contexts; any failure is logged and swallowed so
+        a chain-write hiccup never breaks tool execution.
+        """
+        event_type = "EXECUTED" if success else "FAILED"
+        try:
+            from gaia.approvals import store as _approval_store
+
+            payload = {
+                "command": command,
+                "exit_code": exit_code,
+                "outcome": "success" if success else "failure",
+            }
+            _approval_store.record_event(
+                approval_id,
+                event_type,
+                session_id=session_id or None,
+                payload_json=json.dumps(payload, sort_keys=True, separators=(",", ":")),
+                metadata_json=json.dumps({"source": "post_tool_use"}),
+            )
+            logger.info(
+                "Recorded %s event for approval_id=%s (exit=%d)",
+                event_type, approval_id[:16], exit_code,
+            )
+        except Exception as exc:
+            logger.warning(
+                "Failed to record %s event for approval_id=%s (non-fatal): %s",
+                event_type, approval_id[:16], exc,
+            )
+
     # ------------------------------------------------------------------ #
     # _handle_ask_user_question_result: grant activation from user answer
     # ------------------------------------------------------------------ #

package/dist/gaia-security/hooks/modules/agents/handoff_persister.py

@@ -170,19 +170,30 @@ def _intake_command_set_pending(
     }
 
     try:
-        from gaia.approvals.store import insert_requested
+        from gaia.approvals.store import derive_command_set_id, insert_requested
     except ImportError:
         import pathlib as _pl
         import sys as _sys
 
         _repo_root = _pl.Path(__file__).resolve().parent.parent.parent.parent
         _sys.path.insert(0, str(_repo_root))
-        from gaia.approvals.store import insert_requested
+        from gaia.approvals.store import derive_command_set_id, insert_requested
+
+    # Derive the PUBLIC approval_id deterministically from the post-filter
+    # mutative command strings. Because the id is content-derived (not uuid4),
+    # the orchestrator reproduces the SAME id from the command_set it reads in
+    # the contract via `gaia approvals derive-id` -- no DB search, no
+    # cross-session miss. The list passed here is the SAME list the CLI helper
+    # derives over (post-mutative-filter), so both sides agree.
+    derived_id = derive_command_set_id(
+        [it["command"] for it in command_set_items]
+    )
 
     approval_id = insert_requested(
         sealed_payload,
         agent_id=agent_id,
         session_id=session_id or None,
+        approval_id=derived_id,
     )
     logger.info(
         "INTAKE: plan-first COMMAND_SET pending created approval_id=%s items=%d",

package/dist/gaia-security/hooks/modules/tools/bash_validator.py

@@ -90,6 +90,11 @@ class BashValidationResult:
     # plain error string (exit 2).  Used for structured block responses that
     # should correct the agent rather than terminate execution.
     block_response: Optional[Dict[str, Any]] = None
+    # When a T3 command is allowed because it matched (and consumed) an active
+    # grant, this carries the approval_id of that grant. The adapter stashes it
+    # in HookState so PostToolUse can append an EXECUTED/FAILED event to the
+    # approval_events chain for this approval. None for non-T3 / no-grant paths.
+    consumed_approval_id: Optional[str] = None
 
     def __post_init__(self):
         if self.suggestions is None:
@@ -667,6 +672,7 @@ class BashValidator:
                     allowed=True,
                     tier=SecurityTier.T3_BLOCKED,
                     reason="Command-set grant matched",
+                    consumed_approval_id=cs_approval_id,
                 )
 
             # DB-primary + filesystem-fallback grant check.
@@ -720,6 +726,7 @@ class BashValidator:
                         allowed=True,
                         tier=SecurityTier.T3_BLOCKED,
                         reason="Grant confirmed",
+                        consumed_approval_id=db_approval_id,
                     )
                 else:
                     # Filesystem grant exists, not yet confirmed -- GAIA approved,
@@ -733,6 +740,7 @@ class BashValidator:
                         allowed=True,
                         tier=SecurityTier.T3_BLOCKED,
                         reason="Grant active, pending confirmation",
+                        consumed_approval_id=db_approval_id,
                     )
             else:
                 # Converge on the single T3 decision point.  When there is an
@@ -808,6 +816,7 @@ class BashValidator:
                             allowed=True,
                             tier=SecurityTier.T3_BLOCKED,
                             reason="Command-set grant matched",
+                            consumed_approval_id=cs_approval_id,
                         )
 
                     grant = check_approval_grant(command, session_id=session_id)
@@ -859,6 +868,7 @@ class BashValidator:
                                 allowed=True,
                                 tier=SecurityTier.T3_BLOCKED,
                                 reason="Grant confirmed",
+                                consumed_approval_id=db_approval_id,
                             )
                         else:
                             logger.info(
@@ -870,6 +880,7 @@ class BashValidator:
                                 allowed=True,
                                 tier=SecurityTier.T3_BLOCKED,
                                 reason="Grant active, pending confirmation",
+                                consumed_approval_id=db_approval_id,
                             )
 
                     # No grant matched -- converge on the single T3 decision
@@ -939,10 +950,18 @@ class BashValidator:
             key=lambda t: tier_order.index(t.value),
         )
 
+        # Propagate the consumed approval_id from whichever component matched a
+        # grant, so PostToolUse can append EXECUTED/FAILED for that approval.
+        consumed_approval_id = next(
+            (r.consumed_approval_id for r in component_results if r.consumed_approval_id),
+            None,
+        )
+
         return BashValidationResult(
             allowed=True,
             tier=highest_tier,
             reason=f"All {len(components)} components validated",
+            consumed_approval_id=consumed_approval_id,
         )
 
     def _phase4_check_composition(

package/gaia/approvals/__init__.py

@@ -6,7 +6,8 @@ Public surface:
     chain.ChainTamperError
     chain.insert_event(con, approval_id, event_type, ...) -> int
 
-    store.insert_requested(sealed_payload, *, agent_id, session_id, con=None) -> str
+    store.insert_requested(sealed_payload, *, agent_id, session_id, approval_id=None, con=None) -> str
+    store.derive_command_set_id(commands) -> str  -- content-derived COMMAND_SET id
     store.record_event(approval_id, event_type, *, ..., con=None) -> int
     store.get_pending(session_id=None, all_sessions=False, con=None) -> list[dict]
     store.list_pending(all_sessions=False, session_id=None, con=None) -> list[dict]