feat(maestro): support killApp via close mode

[Rohit3523]

Summary

Supports Maestro killApp (system-initiated process death) end to end, mirroring stopApp plumbing. On Android it dispatches adb shell am kill with its own foreground/liveness preconditions; every other platform ignores the kill mode and falls through to an ordinary close (stopApp-equivalent). No new public CLI surface — killApp stays inside the Maestro compatibility layer.

• contracts: CloseApplicationInput.mode?: 'kill' threaded through closeApplication
• android: killAndroidApp (am kill), with a foreground refusal (android-kill-requires-background-app), a probe-unavailable refusal (android-process-probe-unavailable), and a survived-kill refusal (android-kill-process-survived)
• maestro: killApp IR kind, parser, runtime port, daemon projection to an app-only close carrying killApp dispatch
• daemon: replay dispatch folds killApp; session close (both the stored-session and no-stored-session closeWithoutSession paths) passes mode: kill into closeApplication
• upstream/116_kill_app now classifies identical; declared divergence removed. Touched 31 files.

Validation

Tested commit e676aded6. Focused suites pass: contracts interaction, maestro parser/runtime-port/daemon-port/conformance-verify (14 pass), android app-lifecycle, session-close, replay-maestro-request, fuzz arbitraries, maestro help/docs sync. pnpm check:quick passes. pnpm check:affected --run: fallow audit clean on changed files. Unresolved: check:production-exports reports 68 unused exports, reproduced identical on origin/main, pre-existing.

Live Android emulator replay (agent-device replay --maestro) found and fixed a real foreground-detection race in killAndroidPackage; see the PR review thread for the evidence and remaining caveats.

[thymikee]

Reviewed 78727e3. I found no code defect, but the kill route has only run against adb fakes, and I have one smaller-design question.

The route (Maestro replay → close with closeAppOnly + killApp → Android closeApplication with mode kill → killAndroidApp: focus check, am kill, pidof check) is exercised only through adb exec fakes, and the PR body names real-emulator am kill behaviour as the open risk (app-lifecycle.ts#L510). Two things are unproven: that am kill reaps an app sent to the background with Home, and that the post-kill pidof check does not misread a cached process that is still alive. Can you run a live Android emulator replay through agent-device replay: launchApp → pressKey Home → killApp → launchApp with stopApp false? It passes when killApp succeeds, adb shell pidof <pkg> prints nothing after it, and the relaunch is a cold start. In the same session, launchApp → killApp with the app in the foreground should fail with android-kill-requires-background-app. Please paste both outputs.

Could this be smaller? Only the Android lifecycle owner reads mode. Could packages/platform-android/src/lifecycle.ts call killAndroidApp directly when mode === 'kill', instead of adding Interactor.kill and a fallback branch to the shared contracts type? That would also make it explicit that owners that ignore mode keep force-stop, which matches what Maestro does on iOS. What would have to change first?

Not blocking: the support matrix and replay-e2e.md do not say that a foreground killApp is refused rather than a silent no-op; a process that survives am kill while in the background (for example a foreground service) gets the same android-kill-requires-background-app reason, which is misleading; and mode?: 'stop' | 'kill' is declared twice although nothing writes 'stop'.

All checks are green and there are no conflicts. I could not check whether upstream Maestro's killApp also refuses a foreground app.

[Rohit3523]

Hey! Yeah, I’m going to check the review and push the changes. I’m just waiting for the weekend 😄 It would be great to collaborate and get this thing done together ^_^

[cubic-dev-ai]

7 issues found across 27 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/platform-android/src/__tests__/app-lifecycle-open.test.ts">

<violation number="1" location="packages/platform-android/src/__tests__/app-lifecycle-open.test.ts:239">
P3: These two tests invoke `killAndroidApp` twice because `assertRejectsAppError` (test-utils/app-error.ts) only matches `code`/`message`/`hint`, so a second raw call is needed just to read `details.reason`. In the survivor test the second invocation re-runs the whole failure path, adding another ~2 s of real time (ANDROID_CLOSE_PROCESS_TIMEOUT_MS poll loop) to CI and duplicating identical adb mock traffic. Either extend `ExpectedAppError` with a `details` partial matcher and assert `code`+`hint`+`reason` in one `assertRejectsAppError`, or replace the double call with a single try/catch that asserts code, hint, and `details.reason` together.</violation>
</file>

<file name="src/daemon/session-lifecycle/internal/__tests__/session-close-lifecycle-runtime.test.ts">

<violation number="1" location="src/daemon/session-lifecycle/internal/__tests__/session-close-lifecycle-runtime.test.ts:338">
P3: `mockBindDeviceRuntime.mockImplementation(...)` permanently replaces the shared harness mock for the rest of this file: the file's `beforeEach` only calls `mockClear`, which keeps implementations, so the wrapper (and its `seenModes` closure) stays installed for every subsequent test here. Such tests still pass only because the wrapper delegates to `baseBind`, but the shared mock is left hijacked, which silently couples this test to all later tests in the file. Restore the base implementation at the end of the test, or use two `mockImplementationOnce` registrations.</violation>
</file>

<file name="src/daemon/session-lifecycle/internal/session-close.ts">

<violation number="1" location="src/daemon/session-lifecycle/internal/session-close.ts:152">
P1: This only propagates `kill` through the session-backed dispatcher. A Maestro flow that starts before a daemon session exists enters `closeWithoutSession`, where the omitted mode makes Android perform `stop` instead of `killApp`; pass the same mode through that branch too.</violation>
</file>

<file name="packages/platform-android/src/app-lifecycle.ts">

<violation number="1" location="packages/platform-android/src/app-lifecycle.ts:512">
P2: `killAndroidPackage` proceeds with `am kill` when the foreground probe cannot produce a state. `getAndroidAppState` converts failed or empty dumps into `{}`, so this guard cannot enforce the documented foreground precondition; fail closed or surface the probe failure before dispatching.</violation>

<violation number="2" location="packages/platform-android/src/app-lifecycle.ts:521">
P1: This final liveness check cannot prove the process is gone because `isAndroidPackageProcessRunning` treats every empty `pidof` result as false, including probe failures. Distinguish the normal no-process exit from command errors and fail when the liveness probe itself is unavailable.</violation>
</file>

<file name="packages/maestro/src/internal/__tests__/runtime-port.test.ts">

<violation number="1" location="packages/maestro/src/internal/__tests__/runtime-port.test.ts:187">
P3: The explicit and config app ids are the same value, so this test cannot distinguish the two paths it claims to cover: the dispatcher computes `{ appId: command.appId ?? request.appId }`, and both commands resolve to `com.example.checkout` regardless of which branch is exercised. A regression that, for example, always used the config app id and dropped the explicit `killApp:` app id would still pass. Use a distinct explicit app id (e.g. `com.example.other`) and assert calls[0] receives it while calls[1] falls back to the config id.</violation>
</file>

<file name="packages/platform-android/src/lifecycle.ts">

<violation number="1" location="packages/platform-android/src/lifecycle.ts:69">
P2: `mode: 'kill'` with an empty `positionals` returns success without killing anything. Fall back to `input.appBundleId` (the session-app identity this binding uses everywhere else) and throw `INVALID_ARGS` when neither exists, so a kill that has no target fails loudly instead of reading as success.</violation>
</file>

<sub>Tip: instead of fixing issues one by one fix them all with cubic

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: This only propagates kill through the session-backed dispatcher. A Maestro flow that starts before a daemon session exists enters closeWithoutSession, where the omitted mode makes Android perform stop instead of killApp; pass the same mode through that branch too.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/daemon/session-lifecycle/internal/session-close.ts, line 152:

<comment>This only propagates `kill` through the session-backed dispatcher. A Maestro flow that starts before a daemon session exists enters `closeWithoutSession`, where the omitted mode makes Android perform `stop` instead of `killApp`; pass the same mode through that branch too.</comment>

<file context>
@@ -149,6 +149,7 @@ async function dispatchTargetedPlatformClose(params: {
       outPath: req.flags?.out,
       appBundleId: session.appBundleId,
       surface: session.surface ?? 'app',
+      ...(req.internal?.killApp === true ? { mode: 'kill' as const } : {}),
       execution: applicationLifecycleExecutionFromRequest(req, logPath, session.trace?.outPath),
     });
</file context>

[cubic-dev-ai]

P1: This final liveness check cannot prove the process is gone because isAndroidPackageProcessRunning treats every empty pidof result as false, including probe failures. Distinguish the normal no-process exit from command errors and fail when the liveness probe itself is unavailable.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At packages/platform-android/src/app-lifecycle.ts, line 521:

<comment>This final liveness check cannot prove the process is gone because `isAndroidPackageProcessRunning` treats every empty `pidof` result as false, including probe failures. Distinguish the normal no-process exit from command errors and fail when the liveness probe itself is unavailable.</comment>

<file context>
@@ -488,6 +488,44 @@ export async function closeAndroidApp(device: DeviceInfo, app: string): Promise<
+  }
+  await runAndroidShell(device, ['am', 'kill', packageName]);
+  await waitForAndroidPackageStopped(device, packageName);
+  if (await isAndroidPackageProcessRunning(device, packageName)) {
+    throw new AppError('COMMAND_FAILED', `am kill did not stop ${packageName}`, {
+      reason: 'android-kill-process-survived',
</file context>

[cubic-dev-ai]

P2: killAndroidPackage proceeds with am kill when the foreground probe cannot produce a state. getAndroidAppState converts failed or empty dumps into {}, so this guard cannot enforce the documented foreground precondition; fail closed or surface the probe failure before dispatching.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At packages/platform-android/src/app-lifecycle.ts, line 512:

<comment>`killAndroidPackage` proceeds with `am kill` when the foreground probe cannot produce a state. `getAndroidAppState` converts failed or empty dumps into `{}`, so this guard cannot enforce the documented foreground precondition; fail closed or surface the probe failure before dispatching.</comment>

<file context>
@@ -488,6 +488,44 @@ export async function closeAndroidApp(device: DeviceInfo, app: string): Promise<
+}
+
+async function killAndroidPackage(device: DeviceInfo, packageName: string): Promise<void> {
+  const foreground = await readAndroidForegroundApp(device);
+  if (foreground?.package === packageName) {
+    throw new AppError('COMMAND_FAILED', `Cannot kill foreground app ${packageName}`, {
</file context>

[cubic-dev-ai]

P2: mode: 'kill' with an empty positionals returns success without killing anything. Fall back to input.appBundleId (the session-app identity this binding uses everywhere else) and throw INVALID_ARGS when neither exists, so a kill that has no target fails loudly instead of reading as success.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At packages/platform-android/src/lifecycle.ts, line 69:

<comment>`mode: 'kill'` with an empty `positionals` returns success without killing anything. Fall back to `input.appBundleId` (the session-app identity this binding uses everywhere else) and throw `INVALID_ARGS` when neither exists, so a kill that has no target fails loudly instead of reading as success.</comment>

<file context>
@@ -63,6 +64,11 @@ export function bindAndroidApplicationLifecycle(
       }
+      if (input.mode === 'kill') {
+        const target = input.positionals[0];
+        if (target) await killAndroidApp(device, target);
+        return;
+      }
</file context>

[cubic-dev-ai]

P3: These two tests invoke killAndroidApp twice because assertRejectsAppError (test-utils/app-error.ts) only matches code/message/hint, so a second raw call is needed just to read details.reason. In the survivor test the second invocation re-runs the whole failure path, adding another ~2 s of real time (ANDROID_CLOSE_PROCESS_TIMEOUT_MS poll loop) to CI and duplicating identical adb mock traffic. Either extend ExpectedAppError with a details partial matcher and assert code+hint+reason in one assertRejectsAppError, or replace the double call with a single try/catch that asserts code, hint, and details.reason together.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At packages/platform-android/src/__tests__/app-lifecycle-open.test.ts, line 239:

<comment>These two tests invoke `killAndroidApp` twice because `assertRejectsAppError` (test-utils/app-error.ts) only matches `code`/`message`/`hint`, so a second raw call is needed just to read `details.reason`. In the survivor test the second invocation re-runs the whole failure path, adding another ~2 s of real time (ANDROID_CLOSE_PROCESS_TIMEOUT_MS poll loop) to CI and duplicating identical adb mock traffic. Either extend `ExpectedAppError` with a `details` partial matcher and assert `code`+`hint`+`reason` in one `assertRejectsAppError`, or replace the double call with a single try/catch that asserts code, hint, and `details.reason` together.</comment>

<file context>
@@ -162,6 +162,151 @@ test('closeAndroidApp waits until package process exits after force-stop', async
+    },
+    { serial: 'emulator-5554' },
+    async () => {
+      await assertRejectsAppError(() => killAndroidApp(device, 'com.example.app'), {
+        code: 'COMMAND_FAILED',
+        hint: /Background the app before killApp/,
</file context>

[cubic-dev-ai]

P3: mockBindDeviceRuntime.mockImplementation(...) permanently replaces the shared harness mock for the rest of this file: the file's beforeEach only calls mockClear, which keeps implementations, so the wrapper (and its seenModes closure) stays installed for every subsequent test here. Such tests still pass only because the wrapper delegates to baseBind, but the shared mock is left hijacked, which silently couples this test to all later tests in the file. Restore the base implementation at the end of the test, or use two mockImplementationOnce registrations.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/daemon/session-lifecycle/internal/__tests__/session-close-lifecycle-runtime.test.ts, line 338:

<comment>`mockBindDeviceRuntime.mockImplementation(...)` permanently replaces the shared harness mock for the rest of this file: the file's `beforeEach` only calls `mockClear`, which keeps implementations, so the wrapper (and its `seenModes` closure) stays installed for every subsequent test here. Such tests still pass only because the wrapper delegates to `baseBind`, but the shared mock is left hijacked, which silently couples this test to all later tests in the file. Restore the base implementation at the end of the test, or use two `mockImplementationOnce` registrations.</comment>

<file context>
@@ -319,6 +319,56 @@ test('a supported Android close clears admitted runtime hints exactly once', asy
+  sessionStore.set(sessionName, session);
+  const seenModes: Array<unknown> = [];
+  const baseBind = mockBindDeviceRuntime.getMockImplementation();
+  mockBindDeviceRuntime.mockImplementation(async (boundDevice, use) => {
+    const binding = await baseBind!(boundDevice, use);
+    const innerClose = binding.operations.closeApplication;
</file context>

[cubic-dev-ai]

P3: The explicit and config app ids are the same value, so this test cannot distinguish the two paths it claims to cover: the dispatcher computes { appId: command.appId ?? request.appId }, and both commands resolve to com.example.checkout regardless of which branch is exercised. A regression that, for example, always used the config app id and dropped the explicit killApp: app id would still pass. Use a distinct explicit app id (e.g. com.example.other) and assert calls[0] receives it while calls[1] falls back to the config id.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At packages/maestro/src/internal/__tests__/runtime-port.test.ts, line 187:

<comment>The explicit and config app ids are the same value, so this test cannot distinguish the two paths it claims to cover: the dispatcher computes `{ appId: command.appId ?? request.appId }`, and both commands resolve to `com.example.checkout` regardless of which branch is exercised. A regression that, for example, always used the config app id and dropped the explicit `killApp:` app id would still pass. Use a distinct explicit app id (e.g. `com.example.other`) and assert calls[0] receives it while calls[1] falls back to the config id.</comment>

<file context>
@@ -178,6 +178,25 @@ describe('MaestroRuntimePort', () => {
+      killApp: vi.fn(async (input, context) => record(calls, 'killApp', input, context)),
+    });
+    const program = parseMaestroProgram(
+      ['appId: com.example.checkout', '---', '- killApp: com.example.checkout', '- killApp'].join(
+        '\n',
+      ),
</file context>

[Rohit3523]

The Compatibility & Provenance → Run Fallow audit failure is pre-existing mainline drift, not introduced by this PR.

I reproduced the audit locally at this PR's head (5058165f1, base a79879) and on a clean worktree of plain main (6428c54, zero PR commits). Both fail with the identical gate-new findings, all in files this PR never touches:

• packages/platform-apple/src/runner/runner-contract.ts:40 — unused export APP_NOT_RUNNING_RUNNER_CODE (introduced by mainline fix(ios): never launch a not-running session app from an observation #2852/chore(ios-runner): remove unset env knobs, the dead back wire command, and unreachable paths #2828)
• clone dup:8d32f339 — packages/maestro/src/daemon-port/run-script-http.ts:115-130 × packages/provision-kit/src/install-source-network-transport.ts:74-89
• clone dup:be14bf95 — packages/platform-apple/src/recording/recovery.ts:115-142 × packages/platform-harmonyos/src/recording/recovery.ts:46-72

The 4 complexity hits (conformance-normalize.ts, cli/parser/args.ts) are all marked inherited — this PR only adds 2 trivial case returns to already-critical functions. This PR's own scope (pnpm check:affected) is clean.

Suggested path: the owning mainline changes address those three findings (or get path-keyed baseline updates), then a rebase turns this job green. Per repo rules I'm keeping this PR within its command-family scope and not touching those files or regenerating baselines.

[thymikee]

Following up on f894395 after the earlier evidence-pending review at 78727e3.

The kill route (packages/platform-android/src/app-lifecycle.ts#L510) is still only exercised through adb exec fakes: Maestro replay calls close with closeAppOnly+killApp, lifecycle.ts:70 calls killAndroidPackage, which does a foreground probe, am kill, waitForAndroidPackageStopped, then a pidof check. Neither this delta nor any author comment adds the emulator replay the earlier review asked for. Nobody has shown that am kill actually reaps an app that was sent to background with Home on a real emulator, or that the pidof check correctly reads a backgrounded-but-alive process. Either gap could make killApp fail with android-kill-process-survived, or report success without the process being killed. Can you run agent-device replay on an Android emulator with launchApp, pressKey Home, killApp, launchApp (stopApp: false), and paste output showing killApp succeeded, adb shell pidof <pkg> prints nothing afterward, and the relaunch was a cold start? In the same session, please also run launchApp then killApp with the app still in the foreground and paste the failure carrying reason android-kill-requires-background-app.

Not blocking, can be taken or left: the stricter isAndroidPackageProcessRunning (app-lifecycle.ts#L585) now throws android-process-probe-unavailable on any pidof hiccup, which would abort close/stopApp/relaunch paths on a single flaky probe even after force-stop already succeeded, so should a probe failure only fail the operation whose contract needs proof of death, and should closeWithoutSession's mode spread in session-close.ts#L439 get a direct test (closing with {closeAppOnly, killApp} and no stored session, asserting mode 'kill' reaches platform closeApplication) since nothing exercises it today; also the killAndroidApp re-export in mechanics.ts#L86 looks like dead leftover code with no consumer at head, and the PR body still references the old Interactor.kill design and a different tested commit, so worth cleaning up before merge.

Compatibility & Provenance ran fallow against the pre-rebase base and its findings sit in files this PR does not touch (session-test-harness.ts, runner-contract.ts, runner/index.ts, the apple/harmonyos recovery.ts pair, run-script-http.ts, install-source-network-transport.ts, args.ts); the one file this PR does touch, conformance-normalize.ts, only gets new cases in the lifecycle sub-helpers, not in the flagged canonicalizeUpstreamCommand or canonicalizeAgentCommand, so this failure looks unrelated to the change. I did not re-run the author's reproduction on main, so I can't confirm main actually reproduces the failure being fixed here. I also did not run the unit suites; the regression read above comes from reading the diff and the pre-change code, not from a run. I can't say which Android images in the fleet lack pidof or emit stderr noise from it, so the probe-hardening impact is plausible, not confirmed. And I don't know whether upstream Maestro's killApp also refuses a foreground app.

The remaining requirement before this can merge is the live Android emulator replay described above: killApp after Home must cold-kill the app (empty pidof, cold relaunch), and killApp on a foreground app must fail with android-kill-requires-background-app.

[Rohit3523]

Ran the requested live Android emulator replay (agent-device replay --maestro, real emulator, real installed app, emulator-5554). It found and fixed a real gap — thank you for pushing on this instead of accepting the unit-only evidence.

What the live run found

Flow: launchApp → killApp (app never backgrounded), expecting android-kill-requires-background-app.

The refusal didn't fire. With a temporary debug probe in killAndroidPackage, the daemon log showed exactly why:

DEBUG-KILLPROBE packageName="chat.rocket.android" foreground={"package":"com.google.android.apps.nexuslauncher","activity":"...NexusLauncherActivity"}

adb shell dumpsys activity activities run independently at the same instant showed chat.rocket.android as ResumedActivity — the app was genuinely still foreground. getAndroidAppState tries dumpsys window windows first, falls back to dumpsys window (this Android 16 image has no mCurrentFocus in the windows variant, per the existing code comment), and returns whichever dump answers first. Right after a heavy RN app's cold launchApp, WindowManager's focus dump can still name the previous foreground app for one read while ActivityManager (dumpsys activity activities) already shows the new activity resumed — input-focus transfer lags activity resume. killAndroidPackage trusted that single stale read and skipped the refusal.

Fix (e676aded6, pushed): killAndroidPackage now corroborates a "not the target" foreground read once after a 150ms settle before trusting it enough to proceed — same-app reads still refuse immediately (refusing early is always safe). Added killAndroidApp refuses when a corroborating read shows the target back in the foreground to app-lifecycle-kill.test.ts, which fails without the fix and passes with it. Full suite (573 tests) + typecheck + lint still green.

Caveat: couldn't get a clean live confirmation of the background-kill + cold-relaunch case

This dev machine had several concurrent iOS simulators + an xcodebuild UI-test run + this Android emulator all running at once. Logcat shows the emulator's low-memory killer SIGKILLing freshly-launched processes (ours and several unrelated system packages) ~4 seconds after launch, independent of anything agent-device does — e.g. Process chat.rocket.android (pid 10844) has died: fg TOP followed immediately by Zygote: Process 10844 exited due to signal 9 (Killed). That makes the background scenario's replay output (which reported success) not trustworthy evidence on its own: I can't tell whether am kill reaped it or the OOM killer already had. I don't have a quieter device to rerun this on right now — happy to rerun on request, or if you can point me at a less-loaded emulator/CI lane.

The foreground-refusal fix itself doesn't depend on that confound — it's proven by the debug-instrumented live read above (a value, not a pass/fail) plus the new deterministic unit test.

The three non-blocking cleanups

• PR body: updated — removed the stale Interactor.kill design description (that field doesn't exist; only CloseApplicationInput.mode?: 'kill' does) and the stale tested-commit reference.
• killAndroidApp re-export in mechanics.ts: confirmed dead (the real caller, platform-android/src/lifecycle.ts, imports directly from app-lifecycle.ts; nothing imports it via mechanics.ts) and removed.
• closeWithoutSession mode test: added session-close-without-session-mode.test.ts — closes with {closeAppOnly, killApp} and no stored session, asserts mode: 'kill' reaches the platform closeApplication.

isAndroidPackageProcessRunning probe-hardening

Agree there's a real issue, but it's narrower than "any probe failure aborts close/stopApp/relaunch": waitForAndroidPackageProcessGone's own retry loop (2s budget, 50ms poll) is what should absorb a single transient pidof hiccup — right now the probe's throw escapes that loop instead of being retried within its existing budget, which affects stopApp/closeAndroidApp too, not just killApp. The final "did it survive" checks (this PR's android-kill-process-survived, and implicitly stopApp's completion) should stay fail-closed — treating an unreadable probe as proof of death would be the wrong direction. Fixing the loop's own tolerance touches pre-existing stopApp/closeAndroidApp behavior shared with this PR, so I've left it out of this change rather than expand scope; can follow up in a focused PR if you'd like it done now instead.

[cubic-dev-ai]

2 issues found across 4 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/platform-android/src/app-lifecycle.ts">

<violation number="1" location="packages/platform-android/src/app-lifecycle.ts:582">
P3: The same-app fast path skips the settle in the mirror direction. The stale WMS `mCurrentFocus` lag this fix documents also applies to a read taken right after the user backgrounds the app, so `killApp` issued immediately after `pressKey: Home` can still see the target named and spuriously refuse a legal kill — the hint then tells the user to background an app they already backgrounded. Corroborate this direction too: settle and re-read, refusing only when the confirmatory read still names the target (fail closed on an unreadable confirm).</violation>
</file>

<file name="src/daemon/session-lifecycle/internal/__tests__/session-close-without-session-mode.test.ts">

<violation number="1" location="src/daemon/session-lifecycle/internal/__tests__/session-close-without-session-mode.test.ts:62">
P3: The wrapper discards everything except `input.mode`, so the test stays green if the no-session close later drops or corrupts `positionals`, `surface`, `outPath`, or `ensureReady: true`. Record the full input and assert the key fields alongside `mode` so this path's dispatch contract is pinned, not just the kill bit.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

P3: The same-app fast path skips the settle in the mirror direction. The stale WMS mCurrentFocus lag this fix documents also applies to a read taken right after the user backgrounds the app, so killApp issued immediately after pressKey: Home can still see the target named and spuriously refuse a legal kill — the hint then tells the user to background an app they already backgrounded. Corroborate this direction too: settle and re-read, refusing only when the confirmatory read still names the target (fail closed on an unreadable confirm).

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At packages/platform-android/src/app-lifecycle.ts, line 582:

<comment>The same-app fast path skips the settle in the mirror direction. The stale WMS `mCurrentFocus` lag this fix documents also applies to a read taken right after the user backgrounds the app, so `killApp` issued immediately after `pressKey: Home` can still see the target named and spuriously refuse a legal kill — the hint then tells the user to background an app they already backgrounded. Corroborate this direction too: settle and re-read, refusing only when the confirmatory read still names the target (fail closed on an unreadable confirm).</comment>

<file context>
@@ -561,6 +562,28 @@ async function readAndroidForegroundApp(device: DeviceInfo): Promise<AppStateRun
+  packageName: string,
+): Promise<AppStateRuntimeResult | null> {
+  const first = await readAndroidForegroundApp(device);
+  if (first?.package === packageName) return first;
+  await sleep(ANDROID_KILL_FOREGROUND_STABLE_MS);
+  return await readAndroidForegroundApp(device);
</file context>

Suggested change

	if (first?.package === packageName) return first;
	await sleep(ANDROID_KILL_FOREGROUND_STABLE_MS);
	return await readAndroidForegroundApp(device);
	if (first?.package === packageName) {
	await sleep(ANDROID_KILL_FOREGROUND_STABLE_MS);
	const confirmed = await readAndroidForegroundApp(device);
	if (confirmed && confirmed.package !== packageName) return confirmed;
	return first;
	}
	await sleep(ANDROID_KILL_FOREGROUND_STABLE_MS);
	return await readAndroidForegroundApp(device);

[cubic-dev-ai]

P3: The wrapper discards everything except input.mode, so the test stays green if the no-session close later drops or corrupts positionals, surface, outPath, or ensureReady: true. Record the full input and assert the key fields alongside mode so this path's dispatch contract is pinned, not just the kill bit.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/daemon/session-lifecycle/internal/__tests__/session-close-without-session-mode.test.ts, line 62:

<comment>The wrapper discards everything except `input.mode`, so the test stays green if the no-session close later drops or corrupts `positionals`, `surface`, `outPath`, or `ensureReady: true`. Record the full input and assert the key fields alongside `mode` so this path's dispatch contract is pinned, not just the kill bit.</comment>

<file context>
@@ -0,0 +1,85 @@
+      operations: {
+        ...binding.operations,
+        closeApplication: async (input: Parameters<typeof innerClose>[0]) => {
+          seenModes.push(input.mode);
+        },
+      },
</file context>

[thymikee]

This is a follow-up on f894395 (#2749 (comment)) at e676ade, and the fixes there don't close the gap.

readAndroidForegroundAppSettled (packages/platform-android/src/app-lifecycle.ts#L579) still re-reads the same source that went stale in the live run, just 150 ms later. getAndroidAppState ranks WMS mCurrentFocus ahead of the AMS resumed activity (window-state.ts ANDROID_WINDOW_QUESTIONS.foreground), and three inputs still take the wrong branch on that ranking. If the focus lag after launchApp outlasts 150 ms, which a heavy RN cold start can do, the refusal is skipped, am kill does nothing to the resumed process, and the call fails about 2 s later with android-kill-process-survived and a hint that wrongly claims the app "was backgrounded." If the target is resumed while a system window owns focus, the #592 case the window-state comment already names, the same wrong outcome happens. And the mirror case: the same-app fast path trusts one stale read right after pressKey Home, so the documented legal flow (Home, then killApp) gets refused with android-kill-requires-background-app. So killApp can give the wrong typed reason and hint in either direction. The precondition needs to come from whatever source actually decides if am kill can reap the process, the AMS resumed/top activity or process state, not WMS focus, in both directions: add a resumed-activity question to ANDROID_WINDOW_QUESTIONS in window-state.ts over the existing ANDROID_RESUMED_ACTIVITY_DUMPS tier, have killAndroidPackage read it, then drop the sleep-and-reread helper and its comment. Add a fixture with stale launcher focus plus an mResumedActivity naming the target, which must refuse, and one with target focus plus a resumed launcher, which must proceed.

Not blocking: the new JSDoc and the test headers at app-lifecycle.ts#L565, app-lifecycle-kill.test.ts:53, and session-close-without-session-mode.test.ts:44 carry dated live-run narrative and a "#2749 review:" history that AGENTS.md asks to keep out of implementation comments, worth removing once the fix above lands but not a reason to hold this up on its own.

The iOS runner XCTest testSynthesizedReplacementPacesAnAppOwnedFieldAtItsAcknowledgeWindow (RunnerTests+SynthesizedTextEntryTests.swift:120) is failing in CI, but this PR touches no Swift or runner file, its route is Maestro → daemon close → Android lifecycle, and main recently changed that exact fixture in 94433db, so that failure looks unrelated to this change. The Fallow findings are against a stale base (a798792, 918 changed files); every flagged symbol, clone, and complexity hit sits in a file this PR doesn't touch, or is a pre-existing export (android test-utils/app-error.ts assertThrowsAppError) whose line only moved, identical on main, so a rebase should clear those. There are no known conflicts.

I didn't run the unit suites; the test-validity read above comes from reading the pre-delta and head code, not from executing it. I also don't know how long the WMS focus lag actually runs after launchApp or after Home on a real device, so the launch-lag and Home-lag cases in the finding above are marked likely rather than confirmed, and I haven't checked whether upstream Maestro's own killApp refuses or auto-backgrounds a foreground app. The author's background-kill replay was confounded by the OOM killer by their own account, so am kill's actual reap-and-cold-relaunch behavior is still unproven.

Before this can merge, the kill precondition needs to switch to the AMS resumed activity as above, and then needs a live emulator replay, on an emulator with no concurrent simulators or xcodebuild and no lowmemorykiller/signal 9 for the package in logcat: agent-device replay --maestro for launchApp → pressKey Home → killApp → launchApp (stopApp: false) should show killApp succeeding, adb shell pidof <pkg> printing nothing right after killApp, a logcat line showing am kill did it ("Killing : ... kill background", not the OOM killer), and a cold relaunch (new pid, or am start -W LaunchState COLD); in the same session, launchApp then killApp with no Home should replay-fail with android-kill-requires-background-app, not android-kill-process-survived.