Skip to content

[Bug][Linux] doctor flags a desktop-owned runtime with Start at Login as AT RISK and recommends the refused 'ocx service repair' #6667

Closed

Description

@sungyongcho

Client or integration

Codex App

Area

Platform (Windows / macOS / Linux)

Summary

On Linux, when the OpenCodex desktop app owns the runtime and "Start at Login" is on, ocx doctor still reports Codex restart safety: AT RISK and tells the user to run ocx service repair, a command that is refused while the desktop app owns the runtime.

Desktop startup detection is macOS-only:

  • src/service/desktop-startup.ts: desktopStartupOwnership() and diagnoseMacDesktopStartup() both return undefined when platform !== "darwin".
  • src/codex/autostart-health.ts: desktopEffective requires inputs.platform === "darwin", so protection can never be "desktop" on Linux.

Because desktop is undefined, the classifier also skips the health.desktop?.owned branch ("reopen OpenCodex and check Start at Login"). It falls through to the generic service message, and recommendedCommand becomes ocx service repair instead of null.

The Linux desktop app already registers a login item: tauri-plugin-autostart writes ~/.config/autostart/OpenCodex.desktop with --autostart. After a reboot, the app started ocx start --port 10100 at login, and that proxy served Codex normally.

Expected: on Linux, a desktop-owned runtime with a valid XDG autostart entry for this install is reported as protected by desktop app at login, as it is on macOS. If that can't be verified, doctor should at least show the desktop-owned hint ("reopen OpenCodex and check Start at Login") instead of recommending ocx service repair.

Reproduction

  1. Linux (GNOME), .deb install, with opencodex-proxy.service installed.
  2. Open the OpenCodex desktop app and approve the runtime takeover. Leave "Start at Login" on (~/.config/autostart/OpenCodex.desktop exists).
  3. Reboot and log in. The app starts the proxy. The service unit starts, then stands down with "the desktop app owns the runtime".
  4. Run ocx doctor.
  5. Restart safety shows AT RISK and recommends ocx service repair. Running it is refused with "Background service repair stopped: the desktop app owns the runtime".

Version

2.78.0 (.deb); code paths above are unchanged on dev at 2.79.0

Operating system

Ubuntu 26.04.1 LTS, GNOME Shell 50.1 (Wayland)

Provider and model

No response

Logs or error output

Codex restart safety
  !!  AT RISK after restart (installed service is disabled, stopped, or unhealthy; run 'ocx service repair')
       routing=opencodex-local, service=installed-but-unhealthy, shim=absent

Hints
  - Codex is pinned to the local proxy without persistent startup protection. After restart, requests can reconnect indefinitely. Run 'ocx service repair'.

# ~/.opencodex/service.log at boot
❌ Background service start stopped: the desktop app owns the runtime (install <id>, consent generation 2).
The service registration was left exactly as it is — not re-enabled, not rewritten and not restarted.
Quit the desktop app and run 'ocx service install' to hand the runtime back to this CLI.

Screenshots and supporting files

No response

Redacted configuration

No response

Checks

  • I searched existing issues and documentation.
  • I removed secrets, tokens, account details, request credentials, and personal data.

Activity

  1. added
    bugSomething isn't working
    cliCLI, config inject, packaging flags
    platformOS/service/tray/ACL (Windows-heavy, not Windows-only)
    serviceService lifecycle (WinSW/launchd/scheduler)
    on Oct 6, 2026
  2. lidge-jun commented on Oct 6, 2026

    @lidge-jun
    Owner

    Fixed on dev by #6679 (merge 66a5c9f): ocx doctor now credits a Linux desktop-owned runtime with Start at Login as restart protection when the autostart entry is unambiguous, and no longer recommends the refused ocx service repair. Ships with the next release cut from dev.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingcliCLI, config inject, packaging flagsplatformOS/service/tray/ACL (Windows-heavy, not Windows-only)serviceService lifecycle (WinSW/launchd/scheduler)

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions