Repository navigation
Linux CLI 0.78.0 links libxml2.so.2 again (regression of #1046), fails on Ubuntu 26.04 #4652
Description
Symptom
On Ubuntu 26.04, the 0.78.0 glibc CLI tarball won't start:
$ ~/.local/opt/codexbar/0.78.0/CodexBarCLI --version
codexbar: error while loading shared libraries: libxml2.so.2: cannot open shared object file: No such file or directory
Ubuntu 26.04 ships libxml2 2.15 (libxml2-16, soname libxml2.so.16), so there is no libxml2.so.2 to load. This is the same failure as #1046. 0.77.0 and 0.76.0 run fine on the same machine.
Affected artifacts
From readelf -d on the v0.78.0 release assets:
| Asset | NEEDED libxml2.so.2 |
|---|---|
CodexBarCLI-v0.78.0-linux-x86_64.tar.gz |
yes |
CodexBarCLI-v0.78.0-linux-aarch64.tar.gz |
yes |
CodexBarCLI-v0.78.0-linux-musl-x86_64.tar.gz |
no (static, works) |
CodexBarDesktop-v0.78.0-linux-x86_64.tar.gz |
no |
CodexBarCLI-v0.77.0-linux-x86_64.tar.gz |
no |
Homebrew on Linux installs the linux-x86_64/linux-aarch64 tarballs, so brew install steipete/tap/codexbar should hit this too (not verified).
Cause
#1046 was fixed in 305b6eb by limiting the FoundationXML import in JetBrainsStatusProbe.swift to macOS (#if os(macOS) && canImport(FoundationXML)). #4608 (ac30c44, plugin SVG icons) added Sources/CodexBarCore/Plugins/ProviderPluginIconSVG.swift with the old guard:
#if canImport(FoundationXML)
import FoundationXML
#endifProviderPluginManifest calls ProviderPluginIconSVG.isValid, so CodexBarCore pulls FoundationXML, and with it libxml2.so.2, into the Linux CLI again.
Suggested fix
-
Use the same guard as the JetBrains fix (
#if os(macOS) && canImport(FoundationXML)). On other platforms, haveisValidreturnfalse, which falls back to the monogram. The icon is only drawn by the macOS app anyway. -
Since this has now regressed twice, add a release CI check that fails when a glibc Linux CLI binary lists libxml2 as a dependency. For example, after the build in
release-cli.yml:! readelf -d "$BIN" | grep -q 'libxml2'
Workaround
Use the static CodexBarCLI-v0.78.0-linux-musl-x86_64.tar.gz. It runs serve and usage fine on Ubuntu 26.04 (codex, claude, opencodego all return data). Or stay on 0.77.0.
Environment
- Ubuntu 26.04.1 LTS on WSL2 (kernel 6.18.54.1-microsoft-standard-WSL2), x86_64
libxml2-162.15.2+dfsg-0.1ubuntu0.3, nolibxml2package available- CodexBar 0.78.0 release tarballs
Found and debugged by Claude Code (Claude Opus 5.5) while upgrading the CLI.
Activity
clawsweeper commentedon Oct 19, 2026
Codex review: this still needs some work.
Summary
Keep open: current main retains the FoundationXML dependency path implicated in the v0.78.0 Linux startup regression, and no open fix PR was found.
Reproducibility: Current source establishes the shared-core FoundationXML path and the report supplies an affected-release loader trace; no binary execution or independent readelf inspection was performed.
Regression provenance
Possible regression — probable (reviewed change; failure trace). No predecessor PR is attributed.
Next step
Establish a failing Linux artifact dependency regression, then guard SVG XML parsing to macOS and verify both glibc CLI architectures start without libxml2.so.2.
Review details
Best possible solution:
Keep SVG parsing confined to macOS and enforce a libxml2-free dependency contract for both glibc Linux CLI artifacts.
Do we have a high-confidence way to reproduce the issue?
Current source establishes the shared-core FoundationXML path and the report supplies an affected-release loader trace; no binary execution or independent readelf inspection was performed.
Is this the best way to solve the issue?
The proposed platform boundary matches the earlier repair, provided the XML parser body and delegate are also guarded and non-macOS validation returns false; dependency inspection must fail on inspection errors as well as forbidden libraries.
AGENTS.md: found and applied where relevant.
Remaining risk / open question:
Codex review notes: model internal, reasoning medium; reviewed against 92acf2eac671.
Label changes
Label changes:
P1: The latest release reportedly cannot start on an affected supported Linux distribution, blocking every CLI command.impact:crash-loop: The dynamic loader exits before CLI initialization because libxml2.so.2 is unavailable.issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.clawsweeper:source-repro: Current issue advisory state selects this label.clawsweeper:queueable-fix: Current issue advisory state selects this label.clawsweeper:fix-shape-clear: Current issue advisory state selects this label.Label justifications:
P1: The latest release reportedly cannot start on an affected supported Linux distribution, blocking every CLI command.impact:crash-loop: The dynamic loader exits before CLI initialization because libxml2.so.2 is unavailable.Evidence reviewed
Acceptance criteria:
What I checked:
Sources/CodexBarCore/Plugins/ProviderPluginIconSVG.swift:2, 92acf2eac671)Sources/CodexBarCore/Plugins/ProviderPluginManifest.swift:31, 92acf2eac671)Sources/CodexBarCore/Plugins/ProviderPluginIconSVG.swift:2, ac30c447f9d2)Sources/CodexBarCore/Providers/JetBrains/JetBrainsStatusProbe.swift:2, 305b6eb27fb4).github/workflows/release-cli.yml:371, 92acf2eac671)Likely related people:
Sources/CodexBarCore/Plugins/ProviderPluginIconSVG.swift)How this review workflow works
@clawsweeper re-reviewcomments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.@clawsweeper re-reviewor@clawsweeper re-runon an open PR or issue to request a fresh review only.@clawsweeper reviewto request a fresh review only.@clawsweeper explainto ask for more context, or@clawsweeper stopto stop active automation.Reviewed October 19, 2026, 7:30 PM ET / 23:30 UTC.
fix(linux): keep FoundationXML out of the Linux CLI and guard its lin…
steipete commentedon Oct 20, 2026
Fixed in #4653 (e6bfb10). Thanks @simonsteiner for the precise report! The cause was the new plugin SVG icon support in 0.78.0, which pulled FoundationXML (and with it libxml2) into the Linux CLI. SVG parsing is now macOS-only, and CI plus the release builds now check the Linux binary's linked libraries so a libxml2 dependency can't ship again. The fix will be in the next release.