Cache cleaning and Launcher bugfix

[Leay15]

This pull request closes #243.
It includes a fix for workspace cleanup and updates the codex-update-manager version. Also it
introduces several improvements to Linux desktop integration, focusing on multi-instance support, launch actions, and window state handling. The most important changes are summarized below:

Update Manager:

• codex-update-manager now prunes unreferenced updater workspaces and removes heavy build artifacts, preserving only diagnostics and reports.
• Bumped codex-update-manager crate version to 0.8.1.

Linux Desktop Integration Improvements:

• Added a "New Instance" action to the .desktop files (codex-desktop.desktop) for both user-local and system packaging, allowing users to launch multiple Codex instances easily. This includes the necessary environment variables to support multi-instance launching.
• Updated the packaging script (package-common.sh) to reliably inject the new "NewInstance" action and ensure correct desktop file rendering for both updater-enabled and standalone builds.

Launch Action Infrastructure:

• Enhanced the Linux launch action socket logic to support per-instance sockets, using environment variables and XDG directories for better multi-instance and session isolation. The default socket path now considers CODEX_LINUX_INSTANCE_ID and other environment variables, improving robustness.
• Updated tests and core patch registration to cover the new launch action behavior, including validation for the new socket logic and desktop actions.

Window State Handling:

• Added a new patch (applyLinuxReadyToShowWindowStatePatch) that ensures maximized window state is only restored on Linux if the window was previously maximized, preventing unwanted maximize behavior. This patch is integrated into the patch system and tested.

[Leay15]

@avifenesh I found an issue with multiple instances when launching from the app's context menu, and I'm still trying to get it working.

If you can help me test whether it's possible to launch several instances from this context menu, that would be very helpful. I'm not quite sure whether the bug comes from COSMIC or from the .desktop Exec statement.

[avifenesh]

@Leay15 i opened a pr for cleaning up orphan py proc, might be that?

[Leay15]

@avifenesh I'm not quite sure, but I think it might be related, though not the root cause.

I tested this build after a clean system restart, and it still doesn't work, but a normal launch works as expected.

So I don't think it's related to an orphaned py proc.

[avifenesh]

Can you explain exactly the behavior, and maybe some logs?

[Leay15]

If you run ./codex-app/start.sh --new-instance manually, multiple app instances open as expected.

If you select New Instance from the Launcher's context menu:

It won't open a new instance. However, if you select the same option from the context menu of an already opened app, it works:

[avifenesh]

@Leay15 this may be a stale desktop-entry precedence issue rather than the --new-instance launcher path itself.

The split you described makes sense if the app grid/launcher is using ~/.local/share/applications/codex-desktop.desktop, while the already-running app icon is using the packaged entry hinted by BAMF_DESKTOP_FILE_HINT / CHROME_DESKTOP.

On my machine I found exactly that kind of stale local entry:

grep -Hn "^Exec=\|^Actions=\|^\[Desktop Action" \
  ~/.local/share/applications/codex-desktop.desktop \
  /usr/share/applications/codex-desktop.desktop

The local file had an older action/Exec, so a launcher menu could execute the wrong command even though the packaged /usr/share/applications/codex-desktop.desktop is correct and start.sh --new-instance works manually.

A quick way to test this theory is to temporarily move the user-local file aside and refresh the desktop DB/cache:

mv ~/.local/share/applications/codex-desktop.desktop \
  ~/.local/share/applications/codex-desktop.desktop.bak
update-desktop-database ~/.local/share/applications 2>/dev/null || true
update-desktop-database /usr/share/applications 2>/dev/null || true

Then reopen the launcher and try New Instance again. If that fixes it, the PR code is probably fine and the remaining issue is stale local desktop metadata shadowing the packaged desktop file.

[avifenesh]

@Leay15 one more follow-up: I think we can make this defensible/idempotent instead of leaving it as “users may need to delete a stale file”.

First, one repro detail: on Linux, pressing X may only hide the last window to the tray when the System tray option is enabled. So for a clean launcher test, please use the tray Quit, disable System tray, or kill the process. Otherwise there is still a running app and the already-running icon/menu can behave differently from the app-grid/launcher menu.

For the stale desktop-entry case, I’d split the fix like this:

1. User-local installs/updates: keep this idempotent by always rewriting ~/.local/share/applications/codex-desktop.desktop from the current template, then running update-desktop-database ~/.local/share/applications. That should make repeated installs safe.
2. System package installs: I would avoid deleting arbitrary user files from package maintainer scripts. If we add a migration/repair step, make it very narrow and safe: only touch ~/.local/share/applications/codex-desktop.desktop when it clearly looks like our old generated Codex entry, for example Name=Codex Desktop plus old markers such as codex-desktop-open-next, Actions=NewWindow, missing NewInstance, or missing the newer URI mime type. Move it aside to .bak rather than deleting it, then refresh the desktop DB.
3. Add a small test/fixture for the repair logic: old generated local entry gets backed up, a current entry is unchanged, a custom/non-Codex file is untouched, and running the repair twice is a no-op.

That would turn this class of bug into an idempotent migration instead of a one-off support instruction. A small desktop-entry-doctor helper used by the user-local installer/updater feels like the cleanest place; package postinst can either warn or call the same helper only for active users if we’re comfortable with that boundary.

[avifenesh]

One more thing I just checked: the duplicate New Window item in Ubuntu Dock is probably caused by the desktop action id, not only stale files.

Ubuntu Dock adds its own synthetic New Window menu item when app.can_open_new_window() is true, but it skips that synthetic item only if the desktop file already has an action id named exactly new-window:

const actions = appInfo.list_actions();
if (app.can_open_new_window() && actions.indexOf('new-window') === -1) {
  // add synthetic "New Window"
}

So action ids like NewWindow or NewInstance do not suppress the built-in dock item. Then the dock also appends every desktop action afterward, which can produce duplicate/new-window-like entries.

I think the upstreamable fix is to use the conventional desktop action id everywhere:

Actions=new-window;CheckForUpdates;InstallReadyUpdate;

[Desktop Action new-window]
Name=New Window
Exec=env BAMF_DESKTOP_FILE_HINT=/usr/share/applications/codex-desktop.desktop CHROME_DESKTOP=codex-desktop.desktop CODEX_MULTI_LAUNCH=1 /usr/bin/codex-desktop --new-instance

And mirror that for the user-local/AppImage templates. The user-facing label can still be New Window, while the Exec keeps the Codex-specific --new-instance behavior. This should give the launcher/app-grid an explicit action while preventing Ubuntu Dock from showing a second synthetic New Window item.

[Leay15]

@avifenesh thank you so much for that follow up

Let me check all points and perform the modifications

I will let you know 👌🏻