This is a Pi coding agent session from the pi-permission-system extension repo, dated 2026-05-04. The agent was implementing issue #72 (replace the regex-based bash tokenizer with shell-quote).
The file src/external-directory.ts contained a JSDoc comment with an em-dash (—, U+2014):
/**
* Strips content inside single and double quotes from a command string.
* Replaces quoted segments with empty string so paths inside quotes are not tokenized.
* This is a simple regex approach — it cannot handle escaped quotes within strings.
*/The agent's edit tool couldn't match the oldText containing this character, failing five consecutive times before the agent gave up and used a Python script to do the replacement.
| Lines | What happens |
|---|---|
| 58–59 | First edit attempt. Fails: "Could not find edits[1] in src/external-directory.ts." |
| 62–63 | Second attempt with re-read context. Fails again. |
| 64–67 | Agent tries cat -A (illegal option on macOS), falls back to grep -n to locate the function. |
| 103–104 | Third attempt (later in session, same file, same issue). Fails. |
| 107–108 | Fourth attempt. Fails. |
| 111–112 | Agent uses sed -n '197,225p' src/external-directory.ts | cat -v and sees: This is a simple regex approach M-^@M-^T it cannot handle escaped quotes — the em-dash rendered as its raw UTF-8 bytes. |
| 113 | The diagnosis. Agent's thinking: "The em-dash character — in the comment is encoded as \u2014 (UTF-8: e2 80 94) but cat -v shows it as M-^@M-^T... The Edit tool needs to match exactly, including the Unicode character." |
| 113–114 | Fifth attempt with a smaller oldText block — still fails. |
| 115–116 | Agent uses python3 -c to read the file as raw bytes and confirm the encoding. |
| 117 | Agent's thinking: "The issue is the single quotes in the regex... Let me try using a Python script to do the replacement directly." |
| 117–118 | Agent writes a Python heredoc script that uses \u2014 to match the em-dash and replaces the block. "Replaced successfully." |
The agent used a Python heredoc passed to bash — the \u2014 escape in the triple-quoted string matches the em-dash correctly:
python3 << 'EOF'
with open('src/external-directory.ts', 'r', encoding='utf-8') as f:
content = f.read()
old1 = '''/**
* Strips content inside single and double quotes from a command string.
* Replaces quoted segments with empty string so paths inside quotes are not tokenized.
* This is a simple regex approach \u2014 it cannot handle escaped quotes within strings.
*/
function stripQuotedStrings(command: string): string {
return command.replace(/"[^"]*"/g, "").replace(/\'[^\']*\'/g, "");
}
...'''
new1 = '''/**
* Extracts paths from a bash command string that resolve outside CWD.
...'''
content = content.replace(old1, new1)
with open('src/external-directory.ts', 'w', encoding='utf-8') as f:
f.write(content)
print("Replaced successfully")
EOF- The
edittool's text-matching logic apparently could not round-trip the em-dash character faithfully between the JSON-encodedoldTextparameter and the actual file content on disk. - The agent correctly diagnosed the issue after inspecting the raw bytes, and worked around it by using Python's
\u2014Unicode escape — which Python resolves to the correct byte sequence at runtime. - The same session also mentions a second instance of this class of problem (line 104+), where single-quote characters inside a regex literal (
/'[^']*'/g) compounded the matching difficulty. - The retro for this session (written in a later session) calls out: "rabbit-hole — markdown table column alignment with em-dashes... Should have switched to ASCII hyphen on the first failure."