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

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

Open
#3,406 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
cli, mobile-dev

Research direction

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.

Written by the indexing model from the issue text.

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.

Dominant language
TypeScript
Stars
5k
Forks
334
Avg merge
12h 2m
Merged PRs (30d)
678

Getting set up

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 callstack/agent-device

All issues in callstack/agent-device

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.