Skip to content

Close exec() once, so remote delivery stops raising SyntaxError - #395

Merged
scgopi merged 2 commits into
mainfrom
fix/remote-installer-syntax
Sep 20, 2026
Merged

scgopi merged 2 commits into
mainfrom
fix/remote-installer-syntax

Conversation

@scgopi

@scgopi scgopi commented Sep 20, 2026

Copy link
Copy Markdown
Owner

The bug

Every remote delivery has been a silent no-op since 2026-09-15. On remote hosts and Codespaces there is no ~/.graphcode/bin/graphcode, no briefing, no wake digest and no PROMPT.md — for the whole of 0.1.73.

f6b8af41 (the Windows daemon port) rewrote the installer's embedded python into an exec('def w(p,c): …') helper and closed the call twice. The emitted program ends:

exec('def w(p,c):\n … 0o644)\n')');
                            ^ stray quote and paren

Python raises SyntaxError before writing a byte. The fragment ends in >/dev/null 2>&1 || true, so nothing on the Mac ever saw it.

This is the real cause of both symptoms reported today: a Codespace with no CLI shim, and a loop whose entire brief was a pointer at a PROMPT.md that was never delivered.

Measured

Reconstructing the exact emitted program from the Swift source and running it:

Source Result
f6b8af41^ (before the Windows port) exit 0, file written
origin/main today exit 1, SyntaxError, nothing written
this branch exit 0, shim written mode 0755, briefing written, receipt written

Why no test caught it

Every existing test asserts on the script as text: that it mentions python3, that its base64 manifest decodes, that it is || trued. None of that notices a program python refuses to parse.

RemoteInstallerExecutionTests runs the real fragment under /bin/sh against a scratch HOME and asserts on what landed — contents, the shim's executable bit, the receipt — plus py_compile on the delivered shim, and both halves of the neutered/un-neutered exit-status contract. Skipped, never silently passed, if python3 is absent.

Verification

Step Result
xcodebuild -scheme graphcode test exit=0, ** TEST SUCCEEDED **, Test run with 1903 tests in 200 suites passed
xcodebuild -scheme graphcode-cli build exit=0
xcodebuild -scheme graphcoded build exit=0
swiftlint lint 0 errors
swift format lint --recursive --strict exit=0

TDD evidence

RED: restore the stray quote and run xcodebuild -only-testing:graphcodeTests/RemoteInstallerExecutionTests -> exit=65, theInstallerActuallyWritesEveryFileItCarries fails 5 expectations and aDeliveredShimIsAProgramPythonCanRun fails 2

GREEN: xcodebuild -scheme graphcode -destination platform=macOS test -> exit=0, ** TEST SUCCEEDED **, Test run with 1903 tests in 200 suites passed

REGRESSION: full suite plus graphcode-cli and graphcoded builds, swiftlint and swift format lint -> exit=0 on every step, 0 lint errors, the 1900 pre-existing tests all still pass

scgopi and others added 2 commits September 20, 2026 14:11
`f6b8af41` (the Windows daemon port) rewrote the installer's embedded
python to an `exec('def w(p,c): …')` helper and closed the call twice:
the emitted program ends `exec('…')');`. Python raises SyntaxError on
the stray `')` before writing a byte.

The fragment ends in `>/dev/null 2>&1 || true`, so nothing saw it. Every
remote delivery since 2026-09-15 has been a silent no-op: no CLI shim at
~/.graphcode/bin/graphcode, no briefing, no wake digest, no PROMPT.md —
on every remote host and Codespace, for the whole of 0.1.73. A loop
there could not reach the graph, and one whose goal had been shed to a
file booted pointing at instructions that were never delivered.

Every existing test asserts on the script as *text* — that it mentions
python3, that its manifest decodes, that it is `|| true`d — and none of
that notices a program python will not parse. The new suite runs the
real fragment under /bin/sh against a scratch HOME and checks what
landed, including that the delivered shim itself compiles.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: scgopi <scgopireddy@gmail.com>
@scgopi
scgopi merged commit aff124a into main Sep 20, 2026
8 of 10 checks passed
scgopi added a commit that referenced this pull request Sep 20, 2026
Delivery ended '>/dev/null 2>&1 || true'. The '|| true' is right - a launch must never be blocked because a briefing did not land - but the '>/dev/null 2>&1' is a different decision wearing the same clothes, and it is why #395's SyntaxError survived five days and reached a stable release: the reason went to /dev/null on every dial, on every remote host, every 60 seconds.

Failure stays non-fatal and now reaches the host's own dial log as 'delivery install failed <reason>', flattened to one line, UTF-8 safe, and sized from DialLog's own trim budget rather than a chosen number.

Reviewed adversarially by a sibling loop, which found five defects across two rounds - a UTF-8 split that would have made every other dial entry on the host unfindable, a line length that broke DialLog's trim bound permanently, a trim race this change would have made routine, a dropped exit code, and a test assertion of mine that accepted what the line it replaced forbade. All five fixed and re-verified by running, including that an over-cap log now recovers.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant