Configuración

El servicio de cuentas pertenece a OHarness Cloud. El cliente solo conoce su origen público, no el proyecto de Supabase ni la clave API del proyecto de Composio.

Ubicación	Responsabilidad
`~/.oharness/config.json`	Preferencias generales de runtime: modelos, permisos, registros, sincronización
`~/.oharness/cloud.json`	Dirección pública opcional de Cloud: `{ "siteUrl": "https://oharness.ai" }`
`~/.oharness/plugins.json`	`{ "runtimePlugins": [...] }`; `plugins` opcional para paquetes declarativos
`~/.oharness/mcp.json`	`{ "mcpServers": { ... } }`; los cambios de conectores desde la Web se escriben aquí
Entorno/secretos del despliegue de Cloud	Configuración de Supabase y claves de servicio propiedad de la plataforma
Almacén de credenciales	Credenciales de inicio de sesión del usuario; no está en ninguno de los archivos de configuración anteriores

OHARNESS_HOME redirige los cuatro archivos del cliente. El origen oficial de Cloud es el predeterminado; las anulaciones para autoalojamiento o desarrollo usan OHARNESS_SITE_URL, luego cloud.json y luego el origen público incluido en el paquete. HTTP solo se permite para desarrollo en loopback. La configuración del repositorio no puede elegir el origen de Cloud ni cargar código de plugins de runtime. El Harness.create({ config, runtimePlugins }) programático sigue admitiendo configuraciones proporcionadas explícitamente.

Memoria

Las notas persistentes se configuran en memory dentro de config.json (o del oharness.config.json de un proyecto): límites, recuperación por mensaje y extracción automática. Las notas de proyecto viven como Markdown en <project>/MEMORY/; las notas de usuario entre proyectos viven en ~/.oharness/memory/user/. El consentimiento de sincronización y los índices locales de la máquina se quedan en el directorio del usuario. Una configuración de proyecto puede ajustar la recuperación o desactivar la extracción, pero solo la configuración propia del usuario puede activarla, ya que consume el crédito de modelo del usuario. Memoria enumera todos los ajustes.

Artefactos

Una sesión en un proyecto registrado guarda cada artefacto en <project>/ARTIFACTS/: la revisión más reciente como archivo normal (ARTIFACTS/blue-field.html) y las revisiones que sustituyó en ARTIFACTS/.versions/<name>/v<N>.<ext>. Una sesión puede crear varios artefactos, cada uno en su propio archivo; el mismo nombre desde otra sesión recibe un sufijo (blue-field-2.html). Editar el archivo principal en un editor cambia lo que muestra el panel. ~/.oharness/storage/artifact/<session>.jsonl sigue siendo el índice —qué sesión creó qué, y la versión y los campos de sincronización de cada revisión— sin el contenido. Eliminar una sesión borra el índice y deja los archivos en el proyecto. Las sesiones fuera de un proyecto registrado, y las imágenes rasterizadas, guardan su contenido en el índice como antes. El contenido registrado en línea antes de este cambio se traslada al proyecto la próxima vez que se abre la sesión.

Sincronización

El destino autoalojado y la credencial de sesión solo deben estar en el config.json del usuario:

{
  "sync": {
    "url": "https://sync.example.com",
    "token": "opaque-session-token",
    "enabled": true
  }
}

La precedencia actual es sync.url del usuario, luego OHARNESS_SYNC_URL y luego el destino oficial integrado. La configuración del repositorio no puede fijar la URL, el token ni el equipo, porque eso permitiría que un repositorio clonado redirigiera las transcripciones; solo puede desactivar la sincronización o añadir exclusiones. Reinicia OHarness después de cambiar el destino. Consulta Ejecutar tu propio servidor de sincronización para desplegar el servicio incluido y Protocolo de sincronización para implementar uno compatible.

Migración compatible

Las secciones existentes de config.json solo se leen como respaldo mientras falte su archivo separado. Un archivo separado existente es el que manda, incluso si es una lista de plugins vacía o un mapa MCP vacío. Se acepta el antiguo account.siteUrl; el cliente ya no usa los campos antiguos de Supabase.

npm run config:migrate             # Preview filenames only; no secrets printed
npm run config:migrate -- --apply  # Back up, split, then clean the old sections

La migración conserva las preferencias no relacionadas y no sobrescribe los archivos separados existentes. Guarda una copia de seguridad privada config.before-split.<id>.json y escribe la configuración general al final. Los archivos se sustituyen de forma atómica con modo 0600. No edites la configuración mientras se ejecuta la migración ni lances varios procesos de migración a la vez. La copia de seguridad puede contener credenciales antiguas: mantenla privada y elimínala tú mismo tras comprobarlo todo. La migración nunca modifica las credenciales de inicio de sesión ni autoriza apps.

Transporte de la cuenta

El inicio de sesión desde el navegador sigue usando /auth/desktop y /api/desktop/exchange de Cloud. La renovación y el respaldo por OTP en la terminal usan ahora /api/desktop/auth/refresh, /otp y /verify. Actualiza Cloud antes de reiniciar un cliente actualizado. Un Cloud antiguo devuelve un error explícito; el cliente no recurre a llamadas directas a Supabase.

Cloud usa su proyecto de autenticación configurado, valida las entradas, limita las solicitudes y el tamaño de las respuestas, y devuelve solo los campos de sesión. Los tokens nunca se registran ni se incluyen en los errores. Las solicitudes no se reintentan automáticamente; las respuestas son no-store. Las credenciales obtenidas recientemente registran su origen de Cloud; cambiarlo exige volver a iniciar sesión antes de renovar. Las credenciales antiguas adquieren este origen en la primera renovación correcta contra la dirección de Cloud de confianza actual.

El límite de solicitudes del endpoint de Cloud es por proceso. Los despliegues en producción también deberían aplicar un límite compartido en el edge. Los ajustes de Supabase del sitio web siguen en el proyecto de Cloud; esta migración no requiere cambios en el esquema de la base de datos.

El conector en la nube alojado mantiene la clave de Composio y la lista de apps permitidas en Cloud. Su plugin de runtime integrado connector-cloud muestra tarjetas de autorización en el chat Web y reanuda la herramienta en espera tras verificar la vinculación. plugins.json controla el interruptor del plugin; no contiene credenciales de la plataforma.

← Proveedores y modelos Permisos →