You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi @iamtoruk — thanks for CodeBurn, it is genuinely useful, and the provider coverage is impressive.
I maintain FlatPark, a small hub that offers Flatpak installs for apps that aren't on Flathub, and I've packaged the CodeBurn desktop app there. I'm opening this issue because there was no existing thread for it — and because I saw #970 and the app/flathub/ manifest in your tree, so this is clearly a path you already wanted.
It uses Flatpak extra-data: the package downloads your official codeburn-desktop_<ver>_amd64.deb from GitHub Releases at install time, unmodified, and a resolver tracks new desktop-v* tags automatically. I don't rehost, patch or rebuild anything — the bytes users run are yours. Same shape as your own manifest otherwise: Electron base app, launched through zypak-wrapper.
Two packaging notes, in case either is useful to you:
The read-only enumeration from snap: strict confinement with read-only personal-files plug #978 translates straight across. Instead of --filesystem=home, the FlatPark package grants each provider directory separately and read-only (--filesystem=~/.claude:ro, ~/.codex:ro, ~/.config/Cursor/User/globalStorage:ro, and so on — 18 of them), which is the Flatpak spelling of the personal-files plug you settled on for the snap. Your snap list is the better reference of the two, since you enumerated all 25; if you'd like, I'll align ours with it.
Two paths need the app's own env knobs once the grant is narrowed. Flatpak redirects the XDG variables but not $HOME itself, so $HOME/.cache/codeburn lands on the sandbox tmpfs and every launch re-fetches the LiteLLM table and re-parses cold; the wrapper sets CODEBURN_CACHE_DIR into the per-app cache instead. Likewise OPENCODE_DATA_DIR, because OpenCode resolves its store through XDG_DATA_HOME, which Flatpak points inside the sandbox. Both are set only if unset, so a user can override them. (~/.config/codeburn is granted directly, so settings stay shared with a natively installed CLI.)
I've only smoke-tested it myself — it launches, the dashboard renders, and Settings → Providers detects and prices the two tools I actually have on this machine — so my coverage is certainly partial. If you have time to put it through real use and see what breaks, I'd genuinely appreciate it. And if there's anything in the packaging you'd want changed — permissions, the env knobs, metadata, anything — you're very welcome to open a PR straight against flatpark/flatpark; I'll take it.
If you'd be willing to make FlatPark an officially supported install method — a line in the README's install section, or on codeburn.app — I'd be grateful. The idea is that it takes the Flatpak packaging and distribution work off your plate while giving Linux users a clean install with automatic updates.
And if you'd rather I not list it, just say so and I'll remove it right away, no argument. If you're happy for it to stay, I'll add a blue "developer-approved" shield to its FlatPark page and feature it on the homepage.
Hi @iamtoruk — thanks for CodeBurn, it is genuinely useful, and the provider coverage is impressive.
I maintain FlatPark, a small hub that offers Flatpak installs for apps that aren't on Flathub, and I've packaged the CodeBurn desktop app there. I'm opening this issue because there was no existing thread for it — and because I saw #970 and the
app/flathub/manifest in your tree, so this is clearly a path you already wanted.It uses Flatpak extra-data: the package downloads your official
codeburn-desktop_<ver>_amd64.debfrom GitHub Releases at install time, unmodified, and a resolver tracks newdesktop-v*tags automatically. I don't rehost, patch or rebuild anything — the bytes users run are yours. Same shape as your own manifest otherwise: Electron base app, launched throughzypak-wrapper.App page: https://flatpark.org/apps/org.agentseal.CodeBurn
Two packaging notes, in case either is useful to you:
--filesystem=home, the FlatPark package grants each provider directory separately and read-only (--filesystem=~/.claude:ro,~/.codex:ro,~/.config/Cursor/User/globalStorage:ro, and so on — 18 of them), which is the Flatpak spelling of thepersonal-filesplug you settled on for the snap. Your snap list is the better reference of the two, since you enumerated all 25; if you'd like, I'll align ours with it.$HOMEitself, so$HOME/.cache/codeburnlands on the sandbox tmpfs and every launch re-fetches the LiteLLM table and re-parses cold; the wrapper setsCODEBURN_CACHE_DIRinto the per-app cache instead. LikewiseOPENCODE_DATA_DIR, because OpenCode resolves its store throughXDG_DATA_HOME, which Flatpak points inside the sandbox. Both are set only if unset, so a user can override them. (~/.config/codeburnis granted directly, so settings stay shared with a natively installed CLI.)I've only smoke-tested it myself — it launches, the dashboard renders, and Settings → Providers detects and prices the two tools I actually have on this machine — so my coverage is certainly partial. If you have time to put it through real use and see what breaks, I'd genuinely appreciate it. And if there's anything in the packaging you'd want changed — permissions, the env knobs, metadata, anything — you're very welcome to open a PR straight against flatpark/flatpark; I'll take it.
If you'd be willing to make FlatPark an officially supported install method — a line in the README's install section, or on codeburn.app — I'd be grateful. The idea is that it takes the Flatpak packaging and distribution work off your plate while giving Linux users a clean install with automatic updates.
And if you'd rather I not list it, just say so and I'll remove it right away, no argument. If you're happy for it to stay, I'll add a blue "developer-approved" shield to its FlatPark page and feature it on the homepage.