v0.1.0-beta.4 — aprobación sin bypass, terminal segura y exploración

Vör Commander 0.1.0-beta.4

Esta beta refuerza la confirmación de operaciones sensibles y amplía la exploración segura de proyectos.

Novedades

• vor-approver ya no admite --confirmed: toda firma requiere el diálogo de confirmación, que muestra el digest completo y vuelve a validar la solicitud después de confirmar.
• La terminal segura sin firma usa una lista configurable con coincidencia por ejecutable absoluto y argumentos exactos. La configuración predeterminada solo permite subcomandos de lectura de Git y ejecuta Git con opciones endurecidas.
• Cargo, npm y pytest quedan fuera de la lista segura porque pueden ejecutar código del proyecto. El modo strict desactiva esta vía sin firma.
• Se incorporan las herramientas públicas de solo lectura list_directory, search_files, search_content y file_info.
• Las pruebas son deterministas y CI comprueba que el aprobador de release no recupere el bypass eliminado.

Actualización desde 0.1.0-beta.3

1. Descarga VorCommanderPilot-0.1.0-beta.4-win-x64.zip y comprueba su SHA-256 contra el valor publicado abajo.
2. Extrae el ZIP en una carpeta nueva; no mezcles sus archivos con los de beta.3.
3. Desde PowerShell, ejecuta scripts\installer\install-vor-pilot.ps1 dentro de la carpeta extraída. Usa los mismos valores de InstallRoot, AllowedRoot y DeviceId que en beta.3 si los personalizaste.
4. El instalador detiene beta.3, conserva la política existente y deja la política nueva como policy.example.yaml.new cuando hay diferencias. Revisa y aplica manualmente los cambios que quieras adoptar.
5. Ejecuta scripts\installer\verify-vor-pilot.ps1 desde la instalación para confirmar el estado local.

La actualización no instala servicios de Windows ni abre puertos públicos. Si beta.3 se configuró con una tarea de inicio por usuario, ejecuta el instalador sin -SkipStartupTask para mantenerla registrada.

Integridad del paquete

Archivo: VorCommanderPilot-0.1.0-beta.4-win-x64.zip

SHA-256: ab057d989afd6076051eb6c92892c5a38f91f94e24e3fc3b48e7ba79fa53bcd9

Los binarios no están firmados con Authenticode; verifica siempre el SHA-256 antes de ejecutarlos.

v0.1.0-beta.3 — parche de seguridad y auditoría

Vör Commander 0.1.0-beta.3

Esta beta refuerza la seguridad y la calidad del piloto local para Windows y mejora la experiencia de instalación.

Qué cambia

• Actualiza rustls a 0.23.45 para corregir RUSTSEC-2026-0285.
• Refuerza las rutas de persistencia con firma y limita por bytes las escrituras automáticas.
• Centraliza el tratamiento seguro de rutas mediante vor-path.
• Amplía las comprobaciones de calidad y release con Clippy, cargo audit, pytest y una prueba del control plane.
• Mejora la instalación rápida, la accesibilidad del sitio y sus rutas en inglés bajo /en/.

Actualización desde beta.2

1. Conserva una copia de tu configuración y de los datos de auditoría que necesites.
2. Desinstala beta.2 con su script scripts\installer\uninstall-vor-pilot.ps1.
3. Descarga VorCommanderPilot-0.1.0-beta.3-win-x64.zip y verifica el SHA-256 indicado abajo.
4. Extrae el ZIP y sigue README.md para instalar beta.3 y volver a enlazar tus clientes MCP.
5. Verifica el estado del piloto con scripts\installer\verify-vor-pilot.ps1.

Integridad del paquete

VorCommanderPilot-0.1.0-beta.3-win-x64.zip

SHA-256: 1b7567f0c3d599a02a3f202d72c243a31361b8d6640a56df590b82737ac041b0

Los binarios de esta beta no están firmados con Authenticode; verifica siempre el hash antes de ejecutarlos.

v0.1.0-beta.2 — escritura y terminal con aprobación firmada

Español

La beta.1 era de solo lectura en la práctica: el paquete no incluía el aprobador, así que prepare_write y prepare_terminal devolvían "requiere aprobación" y nadie podía aprobarlo. Lo encontramos al verificar las guías contra la release publicada. La beta.2 lo corrige.

Qué cambia

• Escribir ficheros y ejecutar comandos funciona, con aprobación firmada por el dueño. El paquete incluye vor-approver. El instalador crea tu clave de aprobación Ed25519, protegida con DPAPI de Windows, y arranca el agente con ella como aprobador de confianza.
• scripts\local\approve-vor-request.ps1 muestra qué se pide: acción, ruta o directorio, argumentos del comando o diff, actor, dispositivo y caducidad. Solo firma si escribes APPROVE. Cada aprobación sirve una vez: repetirla devuelve approval_replayed y no ocurre nada.
• La política del paquete es genérica, sin rutas de la máquina de desarrollo. Reinstalar no toca tu política: la nueva queda al lado como policy.example.yaml.new.
• Rotación del token MCP: new-mcp-grant.ps1 -RevokePrevious emite uno nuevo y revoca el anterior. Con una credencial de la beta.1 no puede revocarse por id, y el script lo dice en vez de fingir que lo hizo.
• Enlaces de Cursor y VS Code: las copias .vor-backup que crea el instalador se registran con su hash y la desinstalación solo borra las que siguen intactas.
• verify-vor-pilot.ps1 funciona en una ventana nueva de PowerShell.

Seguridad (sprint de endurecimiento)

• Cada cliente OAuth queda en la auditoría como un actor distinto (<dueño>:oauth:<client_id>). Antes todos aparecían como el mismo.
• El token bearer ya no puede aparecer en los errores de conexión con el relay.
• 11 variantes de evaluación en línea de cmd y PowerShell (cmd /r, -enc, -ec, -CommandWithArgs…) exigen ahora aprobación elevada, como cmd /c. Cambio visible: powershell script.ps1 también la exige.
• El hub limita las peticiones pendientes por dispositivo, rechaza las caducadas sin desconectar al dispositivo y se recupera de un pánico interno.

Actualizar desde la beta.1

No desinstales primero: la desinstalación borra la carpeta de instalación, política incluida, y solo archiva la auditoría. Descomprime la beta.2 y ejecuta su instalador sobre la instalación existente:

.\scripts\installer\install-vor-pilot.ps1 -AllowedRoot 'C:\ruta\a\tu\proyecto'

Tu política se conserva y la nueva queda como policy.example.yaml.new. Si tu política viene de la beta.1, revísala: incluía rutas de la máquina de desarrollo (D:\Proyectos…).

Aprobar una petición

Cuando el asistente llama a prepare_write, prepare_edit o prepare_terminal, recibe request_base64 y challenge, y no cambia nada. Para aprobar:

.\scripts\local\approve-vor-request.ps1 -RequestBase64 '<request_base64>' -Challenge '<challenge>'

Revisa el resumen, escribe APPROVE y entrega al asistente el approval_base64 de la última línea para que llame a commit_write o commit_terminal.

Limitaciones conocidas

• Solo Windows x64 y solo modo local, en tu propio PC. El acceso remoto alojado sigue con lista de espera: https://vorcommander.app/lista-espera
• Claude Desktop no se enlaza solo: usa servidores stdio y Vor expone HTTP. Cursor y VS Code sí.
• La aprobación firmada protege lo que pasa por Vor. Un cliente local que ya tiene su propio shell (por ejemplo, el modo agente de Cursor) puede actuar en tu máquina sin pasar por Vor. La protección fuerte es para el acceso remoto.
• El tope de salida del terminal por MCP es de 512 KiB. La documentación anterior decía 1 MiB por error.
• El ZIP no va firmado con Authenticode: verifícalo por SHA-256.

Verificación

Get-FileHash -Algorithm SHA256 .\VorCommanderPilot-0.1.0-beta.2-win-x64.zip

SHA-256: 52d7b4d87d014414f5a894f285c0b2b0c604ddf4cbb5707001d70396e3b4673a

---

English

beta.1 was read-only in practice: the package did not include the approver, so prepare_write and prepare_terminal returned "approval required" and nobody could approve it. We found it while checking the user guides against the published release. beta.2 fixes it.

What changes

• Writing files and running commands works, with owner-signed approval. The package ships vor-approver. The installer creates your Ed25519 approval key, protected with Windows DPAPI, and starts the agent with it as a trusted approver.
• scripts\local\approve-vor-request.ps1 shows what is being requested: action, path or working directory, command arguments or diff, actor, device and expiry. It only signs if you type APPROVE. Each approval works once: replaying it returns approval_replayed and nothing happens.
• The packaged policy is generic, with no paths from the development machine. Reinstalling leaves your policy alone; the new one is saved next to it as policy.example.yaml.new.
• MCP token rotation: new-mcp-grant.ps1 -RevokePrevious issues a new token and revokes the previous one. A beta.1 credential cannot be revoked by id, and the script says so instead of pretending it did.
• Cursor and VS Code links: the .vor-backup copies the installer creates are recorded with their hash, and uninstall only removes the ones that are still unchanged.
• verify-vor-pilot.ps1 works in a fresh PowerShell window.

Security (hardening sprint)

• Each OAuth client is recorded in the audit as a distinct actor (<owner>:oauth:<client_id>). Before, they all appeared as the same one.
• The bearer token can no longer appear in relay connection errors.
• 11 inline-evaluation variants of cmd and PowerShell (cmd /r, -enc, -ec, -CommandWithArgs…) now require elevated approval, like cmd /c. Visible change: powershell script.ps1 requires it too.
• The hub caps pending requests per device, rejects expired ones without disconnecting the device, and recovers from an internal panic.

Updating from beta.1

Do not uninstall first: uninstall deletes the install folder, policy included, and only archives the audit. Unzip beta.2 and run its installer over the existing install:

.\scripts\installer\install-vor-pilot.ps1 -AllowedRoot 'C:\path\to\your\project'

Your policy is kept and the new one is saved as policy.example.yaml.new. If your policy comes from beta.1, review it: it included paths from the development machine (D:\Proyectos…).

Approving a request

When the assistant calls prepare_write, prepare_edit or prepare_terminal, it gets request_base64 and challenge, and nothing changes. To approve:

.\scripts\local\approve-vor-request.ps1 -RequestBase64 '<request_base64>' -Challenge '<challenge>'

Review the summary, type APPROVE, and give the assistant the approval_base64 from the last line so it can call commit_write or commit_terminal.

Known limitations

• Windows x64 only, local mode only, on your own PC. Hosted remote access still has a waitlist: https://vorcommander.app/en/lista-espera
• Claude Desktop is not linked automatically: it uses stdio servers and Vor exposes HTTP. Cursor and VS Code are.
• Signed approval protects what goes through Vor. A local client that already has its own shell (for example, Cursor's agent mode) can act on your machine without going through Vor. The strong protection is for remote access.
• The terminal output cap over MCP is 512 KiB. Earlier documentation said 1 MiB by mistake.
• The ZIP is not Authenticode-signed: verify it by SHA-256.

Verification

Get-FileHash -Algorithm SHA256 .\VorCommanderPilot-0.1.0-beta.2-win-x64.zip

SHA-256: 52d7b4d87d014414f5a894f285c0b2b0c604ddf4cbb5707001d70396e3b4673a

v0.1.0-beta.1 — beta pública del modo local

Primera beta pública del modo local de Vör Commander. El agente y el gateway MCP corren en tu propio PC con Windows: sin servicio alojado, sin puertos públicos y sin administrador.

Qué incluye

• Lectura: leer ficheros (también por rangos), listar directorios, buscar ficheros y texto (UTF-8, UTF-16 y Windows-1252), información de ficheros, git status/git diff y lista de procesos. Solo dentro de las carpetas que autorizas, con rechazo de .., junctions y enlaces simbólicos.
• Escritura, edición por diff y terminal acotado existen en el código (prepare_write, prepare_edit, prepare_terminal + commit_*, con aprobación firmada Ed25519 de un solo uso), pero en esta beta no se pueden completar: el paquete todavía no incluye el aprobador, así que prepare_* responde approval_required y nada se escribe ni se ejecuta. Esta versión es, en la práctica, de solo lectura. La siguiente beta incluirá la aprobación en el paquete.
• Auditoría encadenada por hash (SQLite + JSONL).
• Instalador por usuario: tarea al iniciar sesión, enlace automático con Cursor y VS Code, desinstalación que conserva la auditoría.

Instalar

1. Descarga VorCommanderPilot-0.1.0-beta.1-win-x64.zip y comprueba su hash:

   (Get-FileHash .\VorCommanderPilot-0.1.0-beta.1-win-x64.zip -Algorithm SHA256).Hash
   # debe ser: 36ba7d2facde69b0dd6968e5d2a8881615a7dd06ecc9248981f9336dd5d2599b

2. Extrae el ZIP y ejecuta:

   .\scripts\installer\install-vor-pilot.ps1 -AllowedRoot 'D:\Projects\MiProyecto'

3. Abre Cursor o VS Code: la herramienta vor-commander ya aparece.

Aviso: los binarios no están firmados con Authenticode todavía, así que Windows SmartScreen puede advertirte. Verifica el hash antes de ejecutar. Puedes compilarlo tú mismo desde este repositorio (scripts\installer\build-vor-pilot-package.ps1, requiere Rust 1.96 y MSVC).

Limitaciones conocidas

• Solo lectura en esta beta (ver arriba).

• verify-vor-pilot.ps1 falla en una ventana nueva de PowerShell con "The variable '$LASTEXITCODE' cannot be retrieved". Es un fallo del script de verificación, no de la instalación: ejecútalo en la misma ventana donde instalaste, o usa status-vor-local.ps1. Se corrige en la siguiente beta.

• La política de ejemplo se regenera en cada reinstalación: guarda aparte tus cambios.

• Claude Desktop todavía no se enlaza: necesita un adaptador stdio, que está en desarrollo. El conector remoto de Claude usa el acceso alojado.

• La aprobación por política (escrituras de bajo riesgo sin firma) aún no está en esta versión.

• El acceso remoto alojado no está abierto al público: apúntate a la lista de espera en https://vorcommander.app.

• Solo Windows.

Dudas y comentarios: Discussions. Seguridad: SECURITY.md.

---

English: first public beta of the local mode (Windows). The agent and MCP gateway run on your own machine (read-only in this beta: the package does not ship the approver yet, so writes and commands cannot be approved), a hash-chained audit log and no public ports. Verify the SHA-256 above; the binaries are not Authenticode-signed yet. Claude Desktop (stdio adapter) and policy-based approval are coming next.