Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#948 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
backend, cli

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
22
Forks
2
Merge medio
7 h 38 min
PR fusionados (30 d)
413

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de callstackincubator/simlock

Todos los issues de callstackincubator/simlock

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.