Repository navigation
Keep FoundationXML out of the Linux CLI again - #4653
Conversation
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Codex review: needs maintainer review before merge. What this changesRestrict plugin SVG parsing to macOS and reject glibc CLI builds that link libxml2. Example: Run CodexBarCLI --version on Ubuntu 26.04 without libxml2.so.2.
Review scores
ProductKind: Bug fix · Worth it: Yes · Fix scope: Complete Regression provenancePossible regression — probable (reviewed change; failure trace). No predecessor PR is attributed. Merge readiness✅ Ready for maintainer review This PR fixes a confirmed Linux startup regression still present on main; no actionable patch defects remain. Priority: P1 Before mergeNone. FindingsNone. Agent review detailsHow this fits togetherPlugin manifests pass optional SVG strings through CodexBarCore validation before the macOS app renders them; the Linux CLI shares that core but does not render icons. flowchart TD
A[Plugin manifest] --> B[CodexBarCore icon validation]
B --> C[macOS XML allowlist]
C --> D[Template image or monogram]
B --> E[Linux rejects optional SVG]
E --> F[CLI without FoundationXML]
F --> G[ELF dependency gate]
Technical reviewBest possible solution: Land the macOS-only parser boundary with the glibc dependency gates while preserving existing icon validation and fallback. Do we have a high-confidence way to reproduce the issue? The affected-release loader trace and artifact dependency comparison match the current-main FoundationXML linkage path; no target code was executed during this read-only review. Is this the best way to solve the issue? This is a focused repair at the shared dependency owner, following the existing JetBrains platform boundary and checking the actual release binary rather than hiding the loader failure. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 92acf2eac671. Provenance checked
TestingProof path: shipped entry point. SecurityNone. EvidenceWhat I checked:
Likely related people:
LabelsLabel changes:
Label justifications:
Rating scale6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior. WorkflowClawSweeper edits this one comment on every review. Comment HistoryReview history (1 earlier review cycle)
Reviewed October 19, 2026, 9:25 PM ET / October 20, 2026, 01:25 UTC (Revision 2). |
|
@clawsweeper re-review |
|
🦞👀 Re-review progress:
|
# Conflicts: # CHANGELOG.md
|
Merged in e6bfb10, thanks @harjothkhara for jumping on this so fast! The Linux CLI no longer links libxml2. We kept your fix, made SVG parsing macOS-only, and added a linkage check (ELF NEEDED entries, any libxml2 SONAME fails) to Linux CI and both glibc release builds, so this can't slip back in unnoticed again. |
Summary
Fixes #4652.
The v0.78.0 glibc Linux CLI tarballs fail to start on Ubuntu 26.04 with
libxml2.so.2: cannot open shared object file. Ubuntu 26.04 ships libxml2 2.15, which provideslibxml2.so.16. This is a regression of #1046, which was fixed by limitingFoundationXMLto macOS inJetBrainsStatusProbe.swift. #4608 then addedProviderPluginIconSVG.swiftwith the old#if canImport(FoundationXML)guard. BecauseProviderPluginManifestcallsProviderPluginIconSVG.isValid, CodexBarCore pulledFoundationXML, and with itlibxml2.so.2, back into the Linux CLI.Changes:
ProviderPluginIconSVG: uses the same#if os(macOS) && canImport(FoundationXML)guard as the JetBrains fix. TheXMLParserallowlist validation is macOS-only. On other platforms,isValidreturnsfalse, so plugin icons fall back to the monogram. Only the macOS app draws plugin icons. No otherFoundationXMLorXMLParseruse exists outside the already-guarded JetBrains probe.build-linux-cliinci.yml, and the two glibc entries inrelease-cli.yml, now fail if the builtCodexBarCLIlists libxml2 in itsreadelf -dNEEDED entries. This regression has now happened twice. The gate fails closed:readelfoutput is captured unmasked, so an inspection error fails the step.matrix.asset-platform == 'linux'.Real behavior proof (Linux CI on this PR)
This comes from this PR's own CI run, 39350172637. The
build-linux-clijobs build the shipped glibcCodexBarCLI(swift build -c release --product CodexBarCLI --static-swift-stdlib) and run the new gate on that exact binary.Startup: the existing "Smoke test CodexBarCLI" step ran the fixed binary on both architectures before the gate, and it passed. That step checks
--help,--version, and the Linuxusage --provider codex --weberror path.Actual dependency list from
readelf -d, linux-x64 job:The linux-arm64 job has the same list, ending in
ld-linux-aarch64.so.1. There's nolibxml2.so.2on either architecture, so the dynamic loader on Ubuntu 26.04, which only shipslibxml2.so.16, has nothing missing to fail on. By contrast, the v0.78.0linux-x86_64andlinux-aarch64release binaries listlibxml2.so.2, perreadelf -din #4652. Both gate steps passed, along withbuild-linux-musl-cli.Commands run
swift build --target CodexBarCoreandswift build --product CodexBarCLI(macOS): passmake check: 0 violationsScripts/test_ci_path_gate.sh: pass, and both workflow YAMLs parsereadelf:readelffails → step failsNEEDED libxml2.so.2→ step failsbuild-linux-clijobs run the new readelf gate against the real glibc CLI, for x64 and arm64.Thanks @simonsteiner for the precise diagnosis.
🤖 Generated with Claude Code