Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

macOS: open can start a second copy of an app that was just launched

Ouverte
#3,406 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
45/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
typescript
Domaine
cli, mobile-dev

Piste de recherche

Start by tracing the macOS open command and its helper that selects an NSRunningApplication; the issue does not name their file paths or tests. Reproduce the quick relaunch case, then inspect how the command launches by bundle ID and how the helper chooses a process. Done means an already running app can be targeted without starting a duplicate or confusing two copies with the same bundle ID.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug ready-for-agent

Summary

On macOS, agent-device open <bundleId> --platform macos can start a second copy of an app that is already running, then drive whichever copy NSRunningApplication.runningApplications(withBundleIdentifier:).first returns.

Repro

  1. Launch an app yourself (e.g. a dev build started by a supervisor process with custom launch arguments).
  2. Within ~0.5–0.75 s, run agent-device open <bundleId> --platform macos.
  3. ps shows two processes for the bundle: the original (with its arguments) and a new one with ppid 1 and no arguments.

Cause: open runs /usr/bin/open [-g] -b <bundleId> without first checking for a running instance. A process that was just spawned isn't listed by LaunchServices yet (lsappinfo lists it ~0.5–0.75 s later), so open -b launches a new copy. If you wait until lsappinfo find bundleid=<id> pid=<pid> returns the process, open attaches and only one copy remains (3/3 runs).

Proposal

  • Before calling open -b, check for a running instance of the bundle (NSRunningApplication or lsappinfo) and attach to it instead of launching.
  • Offer an explicit target, e.g. --pid <pid> or an app path, so a caller that launched the app itself can attach to that exact process.
  • In the macOS helper, resolve the target by pid when one is known, rather than .first, so two copies with the same bundle id can't be confused.

Context: Stim's stim macos launches dev builds this way; we're adding a LaunchServices wait on our side, but the attach behavior would make open safe for any caller.

Langage dominant
TypeScript
Étoiles
5k
Forks
334
Merge moyen
12 h 29 min
PR mergées (30 j)
663

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de callstack/agent-device

Toutes les issues de callstack/agent-device

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.