Claude Code auto memory u Obsidian: contexto verificable

Para las preferencias personales de trabajo, conviene empezar con la auto memory de Claude Code. Para las decisiones que el equipo debe discutir y transferir entre herramientas, son más útiles las notas de Markdown separadas con un propietario y una fuente. Obsidian puede ser el editor de dicho repositorio; instalarlo no conecta las notas con el agente.

No es necesario elegir un método para toda la información. Divida el contexto según quién es responsable de que el registro sea correcto. Por ejemplo, “una respuesta corta es más conveniente para mí” se puede dejar en la memoria personal y “el equipo está transfiriendo informes a un nuevo servicio”, en una nota general con un enlace a la decisión. Es mejor comprobar las rutas y los comandos que ya son visibles en el código real del repositorio para no mantener una copia adicional de los hechos.

¿Qué se almacena exactamente?

Documentación de Claude Code describe la memoria automática como archivos Markdown del proyecto local. Se pueden abrir a través de /memory, editarlos y eliminarlos. Los árboles de trabajo del mismo repositorio Git comparten memoria; no se transfiere automáticamente entre máquinas. El comando /context le ayuda a comprobar los archivos de memoria cargados. La presencia de una nota en el disco no prueba que su contenido esté incluido en la sesión actual.

Un vault de Obsidian es una carpeta con notas y configuraciones. Los archivos Markdown normales permanecen accesibles fuera de la aplicación. Para trabajar con el agente, debe especificar por separado qué archivos leer y darle acceso. Este enfoque no requiere un complemento de Obsidian ni un servidor MCP.

Pregunta	Memoria automática	Vault Markdown independiente
¿Quién ofrece la entrada?	Claude durante el trabajo; una persona lo revisa	Autor de la nota o agente con una tarea explícita
¿Quién corrige un hecho controvertido?	Usuario del proyecto	Responsable designado de la decisión
¿Cómo mostrar un cambio a un colega?	Pasar explícitamente la entrada seleccionada	Compartir el archivo o un Git diff acordado
¿Cómo transferir a otra máquina?	Organizar el traslado por separado	Organizar el acceso o sincronización de una carpeta
¿Dónde buscar obsolescencia?	En notas guardadas	En la fuente y fecha de la próxima revisión

La columna de la derecha describe la organización del trabajo propuesta. Git, propietario y plazo de revisión no aparecen automáticamente al abrir una carpeta en Obsidian.

Prepare una conexión modelo para pruebas de memoria

Si desea probar ambos métodos en Claude Code a través de la API, BetterToken proporciona una conexión compatible con Anthropic. Primero configure el cliente de acuerdo con la guía BetterToken para Claude Code: use su propia API Key y la Base URL de https://bettertoken.ai sin /v1, luego reinicie el cliente y obtenga una respuesta a un mensaje breve. Esto verifica el acceso al modelo; los siguientes pasos verifican su trabajo con notas.

A modo de comparación, mantenga el mismo modelo y la misma tarea: primero pida leer el registro, luego cámbiela y repita la pregunta en una nueva sesión. Por lo tanto, cambiar la conexión no será una variable experimental adicional. BetterToken proporciona llamadas API y la memoria automática y la bóveda aún se administran en el lado de su herramienta. Los fragmentos leídos por el agente pueden terminar en la solicitud del modelo, por lo tanto, utilice una nota de práctica sin información confidencial y no guarde la clave API en la bóveda.

Configure Claude Code a través de BetterToken y pruebe una nota; luego pase al ejemplo siguiente.

Dale un lugar principal a un hecho

Comience con una nota sin información confidencial. En el ejemplo del tutorial, el equipo analiza el formato de exportación; Los significados y los nombres son ficticios. Guarde decisions/report-export.md:

# Report export decision

Status: proposed
Owner: reporting-team
Verified: 2026-09-08
Review-by: 2026-09-22
Source: team decision record to be attached

The proposed export format is CSV.
This is not an approved production requirement.
Before implementation, ask the owner for the approved decision.

Este registro permite distinguir una propuesta y un requisito obligatorio. En un proyecto real, indique la fuente disponible: tarea, acta de reunión o documento de decisión. Hasta que haya confirmación, el agente debe mantener la incertidumbre.

Envíe una tarea específica en una nueva sesión:

Read decisions/report-export.md.
What export format is proposed, and is it approved for production?
Cite the file and identify the missing evidence.
Do not change code or infer approval from the proposal.

Respuesta esperada: CSV propuesto, sin aprobación de producción, se necesita la fuente de la decisión. Este es un criterio de validación, no una promesa de la respuesta correcta del modelo. Si el agente responde con “hay que implementar CSV”, revise qué archivo leyó y citó. Puede haber una nota duplicada, una conversación antigua o una mala interpretación del estado.

Compruebe la actualización y la eliminación

Cambie la nota de práctica: el formato ahora es JSONL, el estado sigue siendo proposed. Inicie una nueva sesión y repita la pregunta. El agente debe indicar JSONL y conservar la limitación anterior. Si devuelve CSV, no agregue otra regla contradictoria: busque la fuente del valor anterior.

Luego elimine la nota de práctica con un administrador de archivos habitual y pregunte en otra sesión nueva dónde se almacena la decisión de formato confirmada. A falta de otra fuente, un resultado útil es un mensaje sobre datos insuficientes. Una respuesta con un valor antiguo significa que hay otra copia u otra fuente; esta es una razón para consultar /memory, los archivos del proyecto y las instrucciones.

Eliminar una nota no la elimina automáticamente del historial de Git, de las copias de seguridad, de los dispositivos sincronizados o de una conversación ya abierta. Esta prueba verifica el comportamiento de una nueva sesión, en lugar de borrar completamente los datos. No incluya claves API, contraseñas y datos personales en el ejercicio.

Ajuste el modo al coste del error

Si trabaja solo y la memoria es principalmente una preferencia, deje la memoria automática y revise las entradas después de cambios significativos en el proyecto. Cuando una acción del equipo depende de un hecho, traslade su versión principal a un documento controlado. En la memoria automática puedes dejar una indicación de dónde buscar la fuente actual, en lugar de copiar la decisión en sí.

Si es necesario, la memoria automática se puede desactivar mediante /memory; El parámetro oficial autoMemoryEnabled controla esta característica. Apagar no reemplaza la verificación de archivos existentes y del contexto ya cargado.

Para una bóveda de equipo, asigne un propietario para registros importantes y un evento de revisión: cambio de API, cancelación de proyecto, migración completa. La fecha ayuda a localizar notas olvidadas, pero no crea una fecha de vencimiento automática. Si usa Git, revise los archivos exactos antes de hacer commit; no agregue la carpeta completa junto con la configuración personal y los archivos adjuntos.

Comience con una decisión y tres preguntas en nuevas sesiones: qué se sabe, qué ha cambiado y qué ya no está confirmado. Si las respuestas se refieren a archivos reales y mantienen la incertidumbre, el método de almacenamiento elegido resuelve su problema. En caso contrario, corrija primero la fuente y el orden de lectura; cambiar el editor no eliminará por sí solo la contradicción.