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

simlock simctl and simlock adb on a worker run only against the caller's lease, and fill the device in

Aperta
  • Qualcosa non va?
#948 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
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
backend, cli

Direzione di ricerca

Start with src/contract/operations.ts and driverPassthrough, then trace #driverPassthrough in src/daemon/dispatcher.ts and the CLI spawn path. Read the lease lookup in the agent-device front and the drivers’ per-verb refusal rules to map where authorization and device insertion belong. Check the existing passthrough tests; done means worker commands are scoped to the caller’s selected lease, with single-lease device filling and the documented refusal cases covered.

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

Descrizione

request:new

Problem

On a worker, simlock simctl <args> and simlock adb <args> are not tied to the caller's lease. driver.passthrough has no authorization beyond the agent role (src/contract/operations.ts, driverPassthrough), the dispatcher resolves the command with only the tool and arguments (src/daemon/dispatcher.ts, #driverPassthrough), and the CLI spawns whatever comes back. Any UDID or serial on the command line runs, held or not. Through a gateway the same command goes through device.exec, which refuses without a lease (#deviceExec, UnknownLeaseError). --lease on a worker is "accepted and ignored" (working-with-a-device.mdx). The docs' own list of product gaps from the website rewrite (commit daa279ada) names this.

Two things follow from scoping the wrappers to the lease:

1. Enforcement of the one promise Simlock makes. simlock simctl install <other agent's UDID> … is refused with a message naming the caller's own device. booted and an adb call without -s are refused when the caller holds a lease, since they can reach another agent's device on the shared set or server. This is still an accident boundary: xcrun simctl stays reachable. It closes the case where an agent follows the rule "use simlock simctl" and still hits the wrong device because it copied the wrong id.

2. Less for the agent to carry. When the caller holds exactly one lease, the device argument can be filled in: simlock simctl install ./MyApp.app and simlock adb install app-debug.apk run against the caller's device. With several leases, --lease <id> picks one, as on a gateway today. The agent no longer copies the UDID out of the grant JSON into every command, and the instructions text shrinks.

Context

Found in the 2026-10-23 product review. The maintainer agreed to pursue it.

Facts for the spec session:

  • The caller's identity on the socket is the requester (SIMLOCK_AGENT_ID, the Claude Code or Codex session id, else the pid). Leases are found by requester, as heldForAnother in the agent-device front already does with lease.list.
  • The admin role bypasses ownsLease today. Whether an operator at the terminal keeps unscoped passthrough (likely yes, with --lease optional) is a decision.
  • Where the device argument sits differs per tool: simctl <verb> <udid> … for most verbs, adb -s <serial> before the verb, devicectl --device <udid>. The drivers already know their refusal lists per verb and can own the insertion rule.
  • --export-env and the grant environment carry no device identifier for virtual devices; filling the argument in removes most of the need (#944 covers the environment side).
  • Tests pin today's behaviour that a worker's passthrough takes no lease; they change with this.

Written by an agent.

Lingua principale
TypeScript
Stelle
22
Fork
2
Merge medio
7h 38m
PR unite (30g)
413

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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 callstackincubator/simlock

Tutte le issue di callstackincubator/simlock

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.