auto-login

name	auto-login
description	Launch the WooCommerce app on a simulator already authenticated into a given store (site credentials, application password, or WPCom), skipping the manual login UI. Meant to be referenced by other skills/workflows that need a logged-in session fast, but also directly runnable.
user-invocable	true
allowed-tools	Bash
argument-hint	<UDID> <site-address> <username> <secret> [auth-type: wporg|applicationPassword|wpcom] [store-id]

Auto-Login

Launch the app already authenticated into a store, skipping the manual login UI. Backed by a DEBUG-only shortcut in ProcessConfiguration.swift that seeds SessionManager credentials + store ID at launch, before AppCoordinator decides whether to show the login screen or the tab bar.

Scope: this skill only launches. It does not build the app, install it, or provision a site — those are the caller's responsibility (see /build, /simulator, and JN site provisioning tools/skills).

Prerequisites

• A booted simulator (use the /simulator skill approach if none is booted)
• The app already built and installed for that simulator, from a DEBUG configuration (the default for simulator builds). If not installed yet, build first and xcrun simctl install <UDID> <path-to-.app>.
• Credentials for the target store:
  • wporg (default) — the wp-admin username + real password (e.g. a fresh Jurassic Ninja site's admin credentials). Works with no extra setup: the app's networking layer automatically does the cookie/nonce handshake and generates+stores a proper application password on the first REST call.
  • applicationPassword — a wp-admin username + an application password created on that site (e.g. via wp user application-password create <user> <name> --porcelain over SSH). Use this if wporg doesn't work for some reason (e.g. a security plugin blocking the wp-login.php handshake).
  • wpcom — a WordPress.com username + auth token, plus the store's real numeric site ID (store-id).

Usage

bash .claude/skills/auto-login/Scripts/launch.sh <UDID> <site-address> <username> <secret> [auth-type] [store-id]

Examples:

# Self-hosted / JN site via its real admin username+password (auth-type defaults to wporg)
bash .claude/skills/auto-login/Scripts/launch.sh "$UDID" https://example-jn-site.com admin "real-admin-password"

# Self-hosted site via an application password instead
bash .claude/skills/auto-login/Scripts/launch.sh "$UDID" https://example-jn-site.com admin "abcd 1234 efgh 5678" applicationPassword

# WPCom-connected site (needs the real site ID)
bash .claude/skills/auto-login/Scripts/launch.sh "$UDID" https://example.com someuser somewpcomtoken wpcom 123456789

The script launches twice: a seeding launch that reads the credentials and persists them to Keychain/UserDefaults, then a second plain relaunch (no debug env vars) that boots already-authenticated from the start — this is what makes launch-time steps gated on already-being-authenticated (push notification registration, analytics identity refresh) run normally, since the seeding launch alone starts out deauthenticated and misses that window. See the comments in launch.sh for details.

After it returns, wait ~3 seconds, then verify: screenshot the simulator or use list_ui_elements (if mobile-mcp is available) and confirm the tab bar is visible (not the login screen), and that the store name matches the target site.

Never commit secrets

Credentials only ever exist as arguments to this one shell invocation and the resulting SIMCTL_CHILD_* environment variables passed to simctl launch — never write them to a file in this repo, a scheme, or any other persisted location.

Known limitations

These stem from the app-side DEBUG shortcut itself and are accepted tradeoffs, not bugs in this script:

• Don't persist these env vars on a personal Xcode scheme. If set that way instead of via this script, every subsequent debug launch — not just the one you intended — silently re-authenticates and re-syncs. Always prefer invoking launch.sh fresh (it only sets them for that one simctl launch call).
• wpcom requires a real store-id. This script validates that, but if you ever set the env vars directly (bypassing this script), a missing/invalid store ID for wpcom credentials silently falls back to the self-hosted placeholder site ID, producing a broken/inconsistent session.
• No error is surfaced on bad credentials. Unlike the real login UI, this shortcut doesn't validate role eligibility, WooCommerce installation, or application-password validity. Bad credentials just produce a blank/broken dashboard — check the simulator's console log (DDLogError) if the store doesn't load.
• wporg needs the wp-login.php cookie/nonce handshake to succeed on first REST call. If a security plugin (e.g. Jetpack's account-protection module) blocks that handshake, wporg will silently fail the same way as any other bad credentials — fall back to applicationPassword in that case.
• If you also pass logout-at-launch in the same launch, auto-login will silently re-authenticate right after it deauthenticates — the two aren't designed to be combined.