Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

fix(ios): refuse open and perf on a locked physical iPhone with a typed reason

Aperta
  • Qualcosa non va?
#2,861 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
ios, typescript
Ambito
cli, mobile, performance, testing-qa

Direzione di ricerca

Start with read-only device discovery and the locked/unlocked control matrix using the selected Xcode toolchain; inspect the full devicectl lockState JSON and bounded runner observations without treating timeouts as locks. Done requires a proven witness, evidence for the required controls, typed refusal behavior for open and both perf samplers, focused tests covering stale PID and unknown states, and the specified affected checks.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

needs-info

Purpose

On a locked physical iPhone, open can report success without foregrounding the app, while perf frames and perf memory sample surface misleading xctrace errors. The original repro was iPhone18,1 on iOS 27 over Wi-Fi: devicectl device info lockState returned passcodeRequired: false while the phone was visibly locked. A process ID or a successful devicectl process launch is not proof that the target reached foreground.

Research gate: prove the signal before implementing a refusal

Use one verified, online physical iPhone and a compatible Xcode toolchain. Record UDID selection by read-only discovery; do not guess a device. Capture the same app/session through unlocked foreground, locked after auto-lock, and unlocked again. For each state record the structured devicectl device info lockState JSON, CoreDevice launch result, and any runner-side observation. Repeat once with the app already running so stale PID reuse is exercised. Do not use stderr text, passcodeRequired, or process existence as the discriminator.

Investigate in this order:

  1. Inspect the full CoreDevice lock-state JSON for an actual state field that changes with the screen lock. A field is usable only if the locked and unlocked controls differ consistently; a command timeout or unavailable tunnel is unknown, not locked.
  2. If CoreDevice has no discriminator, test a bounded runner observation. Apple documents UIApplication.isProtectedDataAvailable == false when data protection is enabled and the device is locked; establish whether the runner can read it while locked and whether this test device enables data protection. Also compare XCUIApplication state / SpringBoard lock-screen observation, distinguishing a real lock from Home, another foreground app, a permission alert, and a dead app.
  3. If no direct lock signal survives those controls, test an app-foreground witness after launch. Call its result target-not-foreground, not device_locked; use a lock hint only if an independent lock witness corroborates it. Do not relabel generic xctrace failures as locks.

The current host probe (2026-09-24) could not validate a signal: the discovered iPhone18,1 on iOS 27.0 had a disconnected CoreDevice tunnel, and a bounded lockState --timeout 8 timed out. The selected Xcode was 26.2. This is an access/toolchain limitation, not evidence of a lock. Apple API references: protected data availability, XCTest application state.

Implementation plan after a witness passes the matrix

  • Put one physical-iOS readiness observation at the Apple lifecycle/perf owner, exposed as a typed result such as locked | unlocked | unknown (or a more honest foreground-specific result if that is all the witness proves). Keep the probe bounded below the required operation's budget. No persistent cached lock bit: the phone may lock between commands.
  • Have open refuse before committing a successful session/open outcome; a launch PID alone is insufficient. If the best witness is post-launch, verify foreground before success. Have both physical-iOS perf samplers consult the same observation before starting xctrace. Keep simulator/macOS behavior unchanged. Preserve typed AppError details and hint through the daemon response.
  • For a proven lock, return a typed reason device_locked with an unlock hint. For a foreground-only witness, return target-not-foreground with an accurate hint. unknown must not be called locked; propagate the underlying availability/error outcome without inventing a lock.
  • Prefer one owner and one reusable state result over three command-specific guards or xctrace message matching. Update the owning help/metadata if the command's observable behavior changes.

Completion conditions

  • Attach a locked/unlocked/locked or unlocked/locked/unlocked evidence table, exact commands, toolchain, and witness values to the PR. Show the Home/other-app/dead-app controls for any foreground proxy.
  • A planted-red test shows the stale-PID success path before the fix. Focused tests cover open, perf frames, perf memory sample, and an inconclusive probe; they assert no xctrace start after a proven lock and no false device_locked for unknown/ordinary background state.
  • On the physical phone, locked commands return the appropriate typed refusal, then the same commands succeed after unlock. Run pnpm check:affected --run and report the exact local checks.

Stop condition

If neither a direct lock witness nor a sound foreground witness passes the controls, do not ship a heuristic or claim this behavior fixed. Post the measurements and keep the implementation issue open for a new device/toolchain signal.

Lingua principale
TypeScript
Stelle
5.1k
Fork
339
Merge medio
12h 50m
PR unite (30g)
632

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di callstack/agent-device

Tutte le issue di callstack/agent-device

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.