Following on from #235: a command line tool installed inside a box is invisible in BoxBuddy. get_apps_in_box enumerates .desktop files in /usr/share/applications, so a box whose whole purpose is a CLI tool shows an empty applications list - I have boxes with an agent CLI installed and BoxBuddy reports nothing in them.
The use case behind it: running the same application under several identities. I want one Claude Code account for work and two personal ones, in the terminal, without logging out and back in each time. Distrobox does this well if each box gets its own home directory (distrobox create --home ~/boxes/work) - the box then keeps its own settings and credentials, while the host's files stay reachable and exports still land in the host's menu and PATH (distrobox-export uses DISTROBOX_HOST_HOME, which is set to the real home). BoxBuddy already exposes that field when creating a box, but nothing in the UI says what it is for, so it reads as a stray option rather than the switch that turns a box into a profile.
Two things would close the gap:
-
List the commands a box actually holds. /usr/local/bin and /opt/*/bin inside the container are almost exactly "what the user installed here". Worth being deliberate about what NOT to scan: ~/.local/bin is the shared host home in a default box, so scanning it lists the host's own tools as if they were in the box - it is only box-local when the box has its own home. And /usr/bin is hopeless: I counted 272 added entries in a freshly created box, because distrobox's own first-run setup installs a pile of packages, so there is no way to tell a user install from the setup.
-
Let a command take a different name on the host. distrobox-export --bin always keeps the command's own name, so two boxes holding claude can only fight over one host entry. If the export could be called claude-work, the profiles would simply coexist.
I have both working, plus a paragraph in docs/tips.md about using a box's own home as an application profile, and will open a PR.
Following on from #235: a command line tool installed inside a box is invisible in BoxBuddy.
get_apps_in_boxenumerates.desktopfiles in/usr/share/applications, so a box whose whole purpose is a CLI tool shows an empty applications list - I have boxes with an agent CLI installed and BoxBuddy reports nothing in them.The use case behind it: running the same application under several identities. I want one Claude Code account for work and two personal ones, in the terminal, without logging out and back in each time. Distrobox does this well if each box gets its own home directory (
distrobox create --home ~/boxes/work) - the box then keeps its own settings and credentials, while the host's files stay reachable and exports still land in the host's menu and PATH (distrobox-exportusesDISTROBOX_HOST_HOME, which is set to the real home). BoxBuddy already exposes that field when creating a box, but nothing in the UI says what it is for, so it reads as a stray option rather than the switch that turns a box into a profile.Two things would close the gap:
List the commands a box actually holds.
/usr/local/binand/opt/*/bininside the container are almost exactly "what the user installed here". Worth being deliberate about what NOT to scan:~/.local/binis the shared host home in a default box, so scanning it lists the host's own tools as if they were in the box - it is only box-local when the box has its own home. And/usr/binis hopeless: I counted 272 added entries in a freshly created box, because distrobox's own first-run setup installs a pile of packages, so there is no way to tell a user install from the setup.Let a command take a different name on the host.
distrobox-export --binalways keeps the command's own name, so two boxes holdingclaudecan only fight over one host entry. If the export could be calledclaude-work, the profiles would simply coexist.I have both working, plus a paragraph in docs/tips.md about using a box's own home as an application profile, and will open a PR.