Summary
In hooks/_lib/push-review-core.sh (around lines 440–469 in the 0.9.2 shipped copy), the SKIP_METADATA JSON construction passes SKIP_OS_PID=$$ and SKIP_OS_PPID=$PPID through jq --arg, which always produces string-typed JSON fields. Downstream auditors querying the REA audit log with jq filters like:
.metadata.os_identity.pid == 1234
will silently fail to match because the stored field is "1234" (string), not 1234 (number).
Root cause
SKIP_OS_PID=$$ # guaranteed numeric (bash internal)
SKIP_OS_PPID=$PPID # guaranteed numeric (bash internal)
SKIP_METADATA=$(jq -n \
--arg os_pid "$SKIP_OS_PID" \ # <-- string-typed
--arg os_ppid "$SKIP_OS_PPID" \ # <-- string-typed
...)
Both values come from bash internals that are guaranteed non-empty numeric. --argjson is safe here.
Reproduction
Set REA_SKIP_PUSH_REVIEW=<reason>, push, then:
jq -r '.metadata.os_identity | {pid_type: (.pid | type), ppid_type: (.ppid | type)}' .rea/audit.jsonl | tail -1
# {"pid_type":"string","ppid_type":"string"}Any operator building an audit-analytics query expecting numeric types silently gets zero matches.
Fix
- --arg os_pid "$SKIP_OS_PID" \
- --arg os_ppid "$SKIP_OS_PPID" \
+ --argjson os_pid "$SKIP_OS_PID" \
+ --argjson os_ppid "$SKIP_OS_PPID" \
Keep os_uid on --arg — id -u 2>/dev/null || echo "" can legitimately return empty, which would break --argjson. (A defensive improvement would be to drop the fallback and let the field be absent rather than empty-string, but that's a separate design question about whether the schema requires os_uid to always be present.)
Severity
MEDIUM — correctness defect; silent schema divergence from stated intent; no security impact.
Context
Flagged by CodeRabbit on PR #1506 in bookedsolidtech/helix. HELiX will backport the fix locally and remove the local patch on next rea upgrade once the upstream fix ships.
Related
Summary
In
hooks/_lib/push-review-core.sh(around lines 440–469 in the 0.9.2 shipped copy), theSKIP_METADATAJSON construction passesSKIP_OS_PID=$$andSKIP_OS_PPID=$PPIDthroughjq --arg, which always produces string-typed JSON fields. Downstream auditors querying the REA audit log with jq filters like:will silently fail to match because the stored field is
"1234"(string), not1234(number).Root cause
Both values come from bash internals that are guaranteed non-empty numeric.
--argjsonis safe here.Reproduction
Set
REA_SKIP_PUSH_REVIEW=<reason>, push, then:Any operator building an audit-analytics query expecting numeric types silently gets zero matches.
Fix
Keep
os_uidon--arg—id -u 2>/dev/null || echo ""can legitimately return empty, which would break--argjson. (A defensive improvement would be to drop the fallback and let the field be absent rather than empty-string, but that's a separate design question about whether the schema requiresos_uidto always be present.)Severity
MEDIUM — correctness defect; silent schema divergence from stated intent; no security impact.
Context
Flagged by CodeRabbit on PR #1506 in
bookedsolidtech/helix. HELiX will backport the fix locally and remove the local patch on nextrea upgradeonce the upstream fix ships.Related
codex.reviewevents (0.10.0) #57 (D/E — codex.review SDK), Self-consistent permissions:rea cache setdenied by REA's own permission hook (0.10.0) #58, Fail loud on cache-query errors (no silent{hit:false}fallback) (0.10.0) #59, obsidian MCP:folderblocked-path matcher triggers on any segment namedrea(0.10.0) #60.push-review-core.shto TypeScript with unit tests). This is defect count 6 found in the bash implementation in a single release cycle.