fix(export): use '#' as sed delimiter (regex '|' was clashing)#3384
Merged
la14-1 merged 1 commit intoOpenRouterTeam:mainfrom May 2, 2026
Merged
fix(export): use '#' as sed delimiter (regex '|' was clashing)#3384la14-1 merged 1 commit intoOpenRouterTeam:mainfrom
la14-1 merged 1 commit intoOpenRouterTeam:mainfrom
Conversation
… parses
Reproduces with: any staged file matching the secret regex (e.g. a test
fixture containing an OpenRouter / Anthropic / OpenAI key shape).
The redact step ran:
sed -i -E "s|${SECRET_REGEX}|${REDACT_PLACEHOLDER}|g" "$f"
SECRET_REGEX is itself a `|`-separated alternation of provider patterns
(`(sk-or-v1-...)|(sk-ant-api...)|(...)`). After bash expansion, sed sees
multiple fields where it expected three, and bails with:
sed: -e expression #1, char 67: unknown option to `s'
The export then fails on the VM ("sprite exec failed (exit 1)") even
though the user already approved the redaction in the host prompt.
Fix: switch the sed delimiter to '#'. None of the regex tokens
(provider prefixes, char classes, quantifiers, PEM marker) contain '#',
and neither does the placeholder, so the substitution is unambiguous.
'|' inside the pattern is now correctly interpreted by sed -E as
alternation, which is what we wanted all along.
Adds a regression test asserting the script uses 's#...#...#g' and
not 's|...|...|g'.
Bumps CLI 1.0.35 -> 1.0.36.
la14-1
approved these changes
May 2, 2026
Member
la14-1
left a comment
There was a problem hiding this comment.
Correct fix for a bug I should have caught in #3383 — sed delimiter '|' collided with the '|'-alternation in SECRET_REGEX, so the redact pass crashed at runtime. '#' is absent from both the regex and the placeholder, so the substitution is now unambiguous. Regression test asserts the exact sed form. Approving.
la14-1
pushed a commit
that referenced
this pull request
May 7, 2026
Exercises the generated sed-based redact loop against a real temp git repo to catch runtime quoting/escaping bugs like the sed delimiter regression in #3384. Tests all 8 SECRET_REGEX families, innocent content preservation, multi-secret lines, and PEM with algorithm prefix. Fixes #3385 Agent: test-engineer Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Repro
Run `spawn export` on a session whose staged tree contains any file matching the secrets regex (e.g. a test fixture with an OpenRouter / Anthropic key shape). Approve the redaction prompt. The VM then errors:
```
⚠ Redacting potential secrets in:
project/test/brain-sync.test.ts
sed: -e expression #1, char 67: unknown option to `s'
■ Export failed: sprite exec failed (exit 1)
```
Cause
The redact step uses:
```bash
sed -i -E "s|${SECRET_REGEX}|${REDACT_PLACEHOLDER}|g" "$f"
```
`SECRET_REGEX` is itself a `|`-separated alternation of provider patterns. After bash expands it, sed sees:
```
s|(sk-or-v1-...)|(sk-ant-api...)|...|REDACTED|g
```
— where every `|` inside the regex looks like another sed field separator, and the parser bails at "unknown option to `s'".
Fix
Swap the sed delimiter to `#`. None of the regex tokens contain `#`, and neither does the placeholder. The `|` inside the pattern is now correctly interpreted by `sed -E` as alternation — which was the intent all along.
Adds a regression test asserting the script contains `'sed -i -E "s#...#...#g"'` and not the broken `'sed -i -E "s|...|...|g"'`.
Bumps CLI `1.0.35` → `1.0.36`.
Test plan
🤖 Generated with Claude Code