Good catch, and the fix is the right approach. I have an overlapping PR (#320) open on the same file targeting the same issue, so I can speak to the tradeoffs directly.

What #320 does: post-extraction sanitization via tr -cd 'a-zA-Z0-9_-'. Simple, but it's a second pass after the unsanitized value is already held in shell memory.

What this PR does: inline sanitization inside the Python extraction call, using the same re.sub(r'[^a-zA-Z0-9_/.\\-~]', '', ...) pattern as mempal_save_hook.sh. This is architecturally cleaner — consistent between hooks, single-pass, and mirrors what the save hook already does.

One minor observation: the charset here (a-zA-Z0-9_/.\\-~) allows path separators and tilde, which is appropriate for TRANSCRIPT_PATH in the save hook but isn't strictly needed for SESSION_ID in the precompact hook (which only goes to a log line). Not a problem — a valid session ID with those characters will still work fine — just noting the rationale if anyone asks why the precompact charset is broader than necessary.

The fix is correct and complete. Happy to close #320 once this lands, since this approach is cleaner.

Good catch — the unsanitized SESSION_ID in the precompact hook needed fixing.

Two notes:

1. Tighten the regex for SESSION_ID

The [^a-zA-Z0-9_/.\\-~] charset is copied from the save hook where it's also used for TRANSCRIPT_PATH (a file path). For a session ID, /, ., and ~ aren't needed. [^a-zA-Z0-9_-] would be tighter and more appropriate here.

2. The save hook's eval pattern is the bigger risk

The save hook does:

eval $(echo "$INPUT" | python3 -c "
...
print(f'SESSION_ID=\"{safe(sid)}\"')
...")

Even with safe(), eval on constructed strings is fragile — if the regex ever has a gap, it's direct shell injection. This PR's approach (simple command substitution via $(...)) is actually safer than what the save hook does. Worth a follow-up issue to refactor the save hook to use the same pattern.