René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"build_run_device/launch_app_device: launchArgs containing leading dashes parsed by devicectl as its own flags (no '--' separator)","articleBody":"## Bug\n\nWhen calling `build_run_device` or `launch_app_device` with `launchArgs` that contain values starting with `-` (e.g. `[\"-FIRDebugEnabled\"]` for Firebase Analytics DebugView), the tools fail with:\n\n```\nFailed to launch app on device: Error: Missing value for '-l \u003cpath\u003e'\nHelp:  -l \u003cpath\u003e  An optional path to write all logging otherwise passed to stdout/stderr.\nUsage: devicectl [--verbose] [--quiet] [--timeout \u003cseconds\u003e] [--json-output \u003cpath\u003e] [--log-output \u003cpath\u003e] \u003csubcommand\u003e\n```\n\nApple's `devicectl` parses the `-FIRDebugEnabled` argument as if it were one of its own flags (it sees the leading `-` and apparently lands on `-l \u003cpath\u003e` expecting a value). This means **no launchArgs that start with `-` can be passed to a running app on device**, which breaks the common case for any framework that reads `ProcessInfo.processInfo.arguments` (Firebase, AppLovin, custom debug flags, etc.).\n\n## Reproduction\n\n```jsonc\n// .mcp.json\n{\n  \"mcpServers\": {\n    \"xcodebuild\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"xcodebuildmcp@latest\", \"mcp\"],\n      \"env\": { \"XCODEBUILDMCP_ENABLED_WORKFLOWS\": \"simulator,device,project-discovery,session-management\" }\n    }\n  }\n}\n```\n\nThen via tool calls:\n\n```jsonc\n// session_set_defaults with a real device's deviceId, workspacePath, scheme, bundleId\n// build_run_device with:\n{ \"launchArgs\": [\"-FIRDebugEnabled\"], \"platform\": \"iOS\" }\n```\n\n→ Build succeeds, install succeeds, launch step fails with the devicectl `-l` error.\n\nSame failure with `launch_app_device({ launchArgs: [\"-FIRDebugEnabled\"] })`.\n\n## Expected\n\n`launchArgs` should be passed to the launched app's `ProcessInfo.processInfo.arguments` — i.e. forwarded *past* devicectl's argument parser. Apple's documented way to do that with `devicectl` is to add a literal `--` separator before the app's args:\n\n```\nxcrun devicectl device process launch \\\n  --device \u003cudid\u003e \\\n  --terminate-existing \\\n  \u003cbundle-id\u003e \\\n  -- -FIRDebugEnabled\n```\n\n## Workaround (confirmed working)\n\nDrop the MCP tool for the launch step and invoke devicectl directly via shell with the `--` separator. Build/install via the MCP works fine; only the launch step needs the workaround:\n\n```bash\nxcrun devicectl device process launch \\\n  --device $DEVICE_ID \\\n  --terminate-existing \\\n  $BUNDLE_ID \\\n  -- -FIRDebugEnabled\n```\n\n## Suggested fix\n\nIn whatever spawns `devicectl device process launch` for `launch_app_device` / `build_run_device`, insert a literal `\"--\"` between devicectl's own flags and the app's launchArgs before forwarding them.\n\n## Environment\n\n- xcodebuildmcp: latest (`npx -y xcodebuildmcp@latest mcp` resolved 2026-05-30)\n- Xcode: 26.5 (DeveloperTools/26.5-17F42)\n- Host: macOS Tahoe 26.2 (arm64)\n- Device: iPhone, iOS 26.5 (real device via USB tunnel)\n- Client: Claude Code with VSCode extension\n\nHappy to test a fix against a real device if it helps.","author":{"url":"https://github.com/phdlance1","@type":"Person","name":"phdlance1"},"datePublished":"2026-05-31T01:23:51.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/434/XcodeBuildMCP/issues/434"}