Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Desktop: keep background startup lightweight and prove Linux packaged-shell E2E

Closed
  • Is something wrong?
#5,493 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
github-actions, tauri, typescript
Domain
ci-cd, desktop, performance, testing-qa

Research direction

Treat the two follow-ups as separate reviewable changes, as the issue author proposes. Start by reviewing the Tauri startup behavior and the Linux CI and installed-artifact workflows described in the issue; identify the relevant entry points and tests in the repository. Done means the hosted AppImage and deb E2E is bounded, isolated, cleanup-safe, and reports failures, while the existing privileged gate remains responsible for installation and update proof; exact-head CI must be green.

Written by the indexing model from the issue text.

Description

priority: P2

Area

Desktop app performance and Linux release confidence.

Why

The Tauri shell now has the correct startup, ownership, drain, updater, and platform-dialog boundaries, but two release questions remain:

  1. A login/autostart launch still navigates the hidden main webview to the full dashboard after the runtime becomes ready. That pays the React dashboard's startup and background-work cost before the user asks to open it.
  2. Linux CI compiles and unit-tests the Rust shell, while the installed-artifact workflow is dispatch-only, lives on dev rather than the default branch, has no registered opencodex-gate-linux runner, and requires already-published artifacts. There is no ordinary hosted proof that the packaged AppImage/deb can show a window, launch the bundled sidecar, become healthy, and drain on close in a session with no tray host.

Proposed work

  • Keep Tauri and the single bundled ocx sidecar; do not add Electron, another daemon, SSH, VM, or multi-window infrastructure.
  • On a hidden autostart launch, retain the lightweight startup surface after Ready and defer loading the full dashboard until the first explicit Open action. Manual launches keep the current immediate dashboard behavior. Startup failures remain visible and retryable.
  • Ensure hidden dashboard/popup surfaces do not retain unnecessary polling; refresh once when shown.
  • Add bounded Linux packaged-shell E2E on GitHub-hosted Ubuntu under Xvfb/dbus. Exercise AppImage and deb payloads without modifying the runner's real home or package database: isolated HOME/CODEX_HOME/OPENCODEX_HOME, packaged binary/resources, real bundled sidecar, health identity, visible window, no-tray close, and confirmed app/runtime exit.
  • Keep the existing self-hosted installed-artifact gate as the later proof for real dpkg/AppImage installation, elevation, takeover, and in-place updates. The hosted E2E must not claim those operations.
  • Record cold/attach readiness time, process-tree RSS, and background request counts as evidence first; set regression budgets only from a reviewed baseline rather than invented thresholds.

Acceptance

  • Linux hosted E2E is bounded, isolated, cleanup-safe, and runs only trusted repository code with read-only workflow permissions.
  • Both package formats exercise the same behavioral assertions and upload a small diagnostic report on failure.
  • No access to /home/ubuntu runtime state and no bare bun test, ocx sync, or daemon restart.
  • Desktop structure documentation distinguishes hosted packaged-shell E2E from the privileged installed-artifact gate.
  • Exact-head CI is green before merge.

@lidge-jun I am taking the Linux packaged-app E2E and the small background-startup efficiency follow-up as separate reviewable PRs. I will keep the release/credential boundary unchanged.

Dominant language
TypeScript
Stars
16.9k
Forks
1.3k
Avg merge
15h 24m
Merged PRs (30d)
678

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from lidge-jun/opencodex

All issues in lidge-jun/opencodex

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.