dsh-permission-rules antepone una lista ordenada de reglas allow / deny / ask a cada llamada de herramienta en la cascada tools/pre-execute — determinista, instantánea, auditable y escrita por ti en YAML plano:

• deny bloquea la llamada; la reason de la regla se convierte en el error visible para el modelo.
• ask usa la costura oficial de aprobación (monta dsh-auto-review para un answerer de segundo modelo, o responde un humano; sin ninguno, el harness falla cerrado).
• allow (y sin coincidencia) delega estrictamente vía next() — los listeners posteriores nunca se cortocircuitan.

Cada acierto y cada paso directo se registra como un evento de sesión permissionRules/decision (solo registro — nada extra se inyecta en el contexto del modelo).

• Emparejamiento rico — globs de nombre de herramienta (incl. mcp__*), selectores de identidad de agente (main / subagent / preset:*), globs o regexes de clave/valor de argumentos (con negación !pattern y una dimensión de clave absent), globs de ruta relativos al workspace a cualquier profundidad de anidamiento, condiciones de host when (variables de entorno, plataforma), y descomposición de comandos de shell (argv: palabra de comando, tokens de argumento, firma de pipeline) para emparejamiento preciso a nivel de token.
• Línea base de alto riesgo integrada — un conjunto deny/ask embarcado (comandos destructivos, escalada de privilegios, descarga-y-ejecución, rutas sensibles) habilitado por defecto y añadido después de las reglas de usuario (una regla de usuario más cercana puede sobrescribirlo); se alterna con builtin.enabled.
• Archivos de reglas jerárquicos — searchUp opcional fusiona cada .dsh/rules.yaml desde el cwd de la sesión hasta la raíz del sistema de archivos, el más cercano primero.
• Despliegue en dry-run — enforce: false audita lo que la política haría mientras deja pasar cada llamada.
• Recarga en caliente — vigilancia Chokidar con debounce; una edición rota conserva las reglas anteriores, nunca falla.
• Fallo ruidoso — YAML inválido, acciones/campos desconocidos, globs/regexes malos, patrones propensos a backtracking o más de maxRules reglas fallan la carga.

# <project>/.dsh/rules.yaml
rules:
  - match: { tools: [bash, pwsh], params: { command: "git push*" }, paths: ["**/secrets/**"] }
    action: deny
    reason: "No pushes from protected paths"

  - match: { tools: [edit, write] }
    action: ask
    reason: "File writes need confirmation"

• Dimensiones de coincidencia — tools (globs, incl. mcp__*), agents (main / subagent / preset:<name>; identidad desconocida nunca coincide — falla cerrado), params (globs o regexes de clave/valor, negación !pattern, dimensión de clave absent), paths (globs relativos al workspace extraídos a cualquier profundidad), when (globs/regexes de variables env + una lista platform cerrada), y network (domains / ips / ports / schemes — globs, comodines, CIDR, rangos de puertos).
• Acciones — allow / deny / ask, evaluadas en orden de archivo, la primera coincidencia gana.
• Metadatos de regla — enabled: false (visible pero inerte), description, tags; los campos desconocidos fallan la carga.
• Schema — un JSON Schema se distribuye en docs/rules-format.schema.json (autocompletado de editor vía # yaml-language-server: $schema=...); el vocabulario completo y una línea base de 5 reglas viven en docs/rules-format.en.md.

Una política de red a nivel de proceso estilo Codex: el tráfico de subprocesos de shell fluye a través de un proxy HTTP/CONNECT local integrado, y cada conexión se decide mediante reglas de red ordenadas o mediante tres modos mapeados sobre los presets oficiales del sandbox:

• deny-all — el preset de sandbox de solo lectura: bloquear todo el tráfico saliente.

• whitelist — el preset workspace-write: permitir los destinos listados, unlisted: ask (o deny) para el resto.

• allow-all — el preset danger-full-access: permitir todo.

• auto (por defecto) — sigue el preset del sandbox; en hosts sin el servicio de política de sandbox se resuelve a autoFallback (allow-all).

• Emparejamiento — match.network con domains / ips / ports / schemes (globs, comodines, CIDR, rangos de puertos; se aceptan puertos YAML numéricos). La extracción de candidatos URL en la ruta caliente tools/pre-execute se dispara sobre argumentos de herramientas web y URLs embebidas en texto de comandos bash/pwsh; los destinos de loopback pueden cortocircuitar reglas según la política loopback.

• Auditoría — las conexiones denegadas anexan permissionRules/network a la sesión propietaria (la misma puerta adaptativa ignorable), con contadores de bloqueo e intercepciones recientes en /rules network y la página de settings.

# 1. install the bundle into your profile
dsh plugin --profile web add "github:PerryLink/dsh-permission-rules#main"

# or from npm (published releases)
dsh plugin --profile web add dsh-permission-rules

# 2. restart and verify the row
dsh --profile web --dump-config | grep -A4 'id: permission-rules'

• canal git (último main): dsh plugin --profile web add "github:PerryLink/dsh-permission-rules#main" — el script prepare compila solo con dependencias de producción.
• canal npm (versiones publicadas): dsh plugin --profile web add dsh-permission-rules.
• canal tarball: pnpm pack en este repo, luego dsh plugin --profile web add ./dsh-permission-rules-<version>.tgz.
• desinstalar: dsh plugin --profile web remove dsh-permission-rules.

Todos los parámetros son campos Schemastery Config (modificables desde cordis.yml). Una sobrescritura dirigida por id reemplaza toda la fila — reafirma cada clave que necesites.

/rules                        list the active rules, their source files, and any last-reload error
/rules list                   explicit alias for the bare listing
/rules reload                 re-read the rule-file chain for this workspace
/rules decisions [n]          show the last n permission decisions of this session (default 10)
/rules test <tool> <json>     dry-evaluate the rules against a hypothetical call

/rules test también acepta banderas iniciales: --cwd <dir>, --env KEY=VALUE (repetible), --agent <selector> (repetible) y --platform <name>. En cadenas multi-archivo (p. ej. searchUp), cada línea de regla listada se atribuye a su propio archivo fuente.

• Permissions: el manifiesto de workshop declara files:read, files:watch, files:write, session:append y network:outbound. Las decisiones ask usan la costura oficial de aprobación — nada se reimplementa ni se evade.
• Data: los archivos de reglas se leen del disco; no se escribe ningún dato de reglas. Sin llamadas al modelo, sin subagentes revisores.
• Session log: permissionRules/decision nunca se inyecta en el contexto del modelo y se anexa con el marcador ignorable: true del sobre, de modo que cualquier build del harness carga el registro.

• Política, no kernel. Los candidatos paths provienen solo de un conjunto documentado de claves de argumento (a cualquier profundidad, con tope), y solo coinciden las rutas relativas al workspace.
• Aquí no hay revisor. El plugin nunca genera subagentes ni llama modelos — producir una decisión ask es el fin de su trabajo.
• Sin cambios de sandbox. La política de sandbox a nivel de SO pertenece a la costura del sandbox, no a este plugin.
• Rechazo ruidoso de mala configuración. Campos YAML desconocidos, acciones desconocidas y patrones malos se rechazan al cargar.
• Límites de backtracking. Los patrones glob se limitan a maxGlobStars expansiones de estrella no acotadas; los patrones regex rechazan cuantificadores anidados no acotados y alternancias literales solapadas cuantificadas.

• Marcador de auditoría en hosts previos al marcador o que rechazan eventos. permissionRules/decision se anexa con ignorable: true; los hosts cuyo Session.append es anterior al marcador (las líneas 0.1.0-rc.1–rc.7 y 0.1.1-rc.1–rc.7) lo descartan silenciosamente, y la línea 0.1.2-alpha rechaza eventos de plugin al leerlos incluso marcados — el runtime detecta ambos antes del primer append y desactiva la auditoría de registro con una advertencia única. Pon allowUnmarkedAudit: true para reactivar; repara registros ya escritos con scripts/repair-session-logs.mjs (su modo strip elimina filas de auditoría donde el marcador no ayuda).
• Los candidatos de ruta son heurísticos. Solo las claves de argumento documentadas alimentan el emparejamiento de rutas, y el emparejamiento relativo al workspace es insensible a mayúsculas ASCII solo con caseInsensitivePaths activado.
• Los globs son un subconjunto conservador. Sin expansión de llaves — escribe dos patrones, o usa modo regex.
• La guardia de backtracking de regex es estructural, no exhaustiva. Prefiere el modo glob para archivos no confiables.

• dsh-permission-rules produce ask; dsh-auto-review responde en la cascada approval/request con un veredicto de segundo modelo de solo lectura (o delega en humanos). Monta ambos para el bucle completo cerrado.
• Probado en integración: permissionRules/decision → approval/asked → autoReview/verdict → approval/decided, con el revisor reemplazado por un mock guionado.
• La política de aprobación never y toda garantía de fallo cerrado del harness oficial permanecen intactas.

Los registros de sesión escritos antes de que existiera el marcador ignorable pueden ser rechazados por builds más nuevas del harness (SessionFormatUnsupportedError). El scripts/repair-session-logs.mjs distribuido reescribe solo las filas de auditoría objetivo para llevar ignorable: true, preservando marcos, con copias de seguridad:

node scripts/repair-session-logs.mjs scan [--home DIR]      # reporta filas ajenas, no cambia nada
node scripts/repair-session-logs.mjs repair [--home DIR] [--dry-run]

--home por defecto es $DSH_HOME/sessions (o ~/.dsh/sessions).

pnpm install            # node ^22.19 || >=24
pnpm run typecheck      # tsc, src + tests
pnpm run lint           # eslint, src + tests + scripts
pnpm test               # vitest: 236 tests, 20 files
pnpm run test:coverage  # coverage gate (90/80/90/90)
pnpm run build          # tsc declarations + tsdown bundles (lib/)
pnpm run pack:check     # build + pack (the published artifact)
node scripts/check-readme-sync.mjs   # five-language README sync gate (also in CI)

Consulta VERIFICATION.md para el registro de verificación end-to-end sin cabeza.

dsh, dsh-plugin, deepseek-harness, permission, policy, allow-deny-ask, approval, safety, network, network-policy, proxy

• @PerryLink — creador y mantenedor: vocabulario y evaluación de reglas, runtime, vigilancia HMR, auditoría de registro de sesión, política de red + proxy, y la documentación en cinco idiomas.
• @22xuan — el informe detallado sobre hosts rc.6 que descartan silenciosamente el marcador ignorable del evento de auditoría (#2) y la discusión del harness upstream; la detección de capacidad de host en runtime v0.4.1 y la corrección de documentación se derivaron directamente de ese análisis.
• @sjh9714 — propuso el corpus compartido de vectores de prueba de sintaxis de reglas (#4, #5), incluido en v0.5.1 como docs/rule-test-vectors/, y aportó los casos límite de descomposición AST en la discusión de diseño.
• @weipeng1999 — la propuesta de descomposición de comandos basada en AST (#8) detrás de la discusión de diseño.
• @alexchenzl — la solicitud de inclusión en el DSH Directory (#7).
• @zl190 — informó y verificó la brecha de compatibilidad del harness 0.1.0-rc.7 (PR #9).
• @cuohua — informó de que la línea 0.1.1-rc sigue descartando el marcador ignorable aunque la compuerta de versión solo cubría 0.1.0 (#11); la compuerta ampliada surgió directamente de ese análisis.

Este proyecto es uno de los 33 complementos de DeepSeek Harness mantenidos por PerryLink. Si este te ayuda, probablemente los demás también:

Apache License 2.0 © 2026 dsh-permission-rules contributors