FIMemory

AI 도구가 연결되고 지시받으면 읽을 수 있는 로컬 저장소.

FIMemory(FI Memory, Future Industries 제작)는 노트를 사용자 컴퓨터에 보관하고, AI 도구를 노트에 연결하여 매 세션마다 같은 프로젝트를 다시 설명하지 않아도 되게 합니다. 저장소는 사용자 파일로 이루어진 평범한 폴더입니다. 독점 형식도, 서버도, 계정도 없으며 어디에도 업로드되지 않습니다. 새 저장소는 기본적으로 저장 시 암호화됩니다. 암호를 선택하면 24단어 복구 문구가 한 번 출력되며, 파일은 어디로 이동하든 비공개로 유지됩니다: git 호스트, 클라우드 백업, USB 스틱. 텍스트 편집기에서 바로 열 수 있는 파일을 선호하시나요? 설정 시 명시적으로 선택하면 일반 텍스트로 저장되며, 암호화된 저장소는 언제든지 읽을 수 있는 Markdown으로 내보낼 수 있습니다. 키만 있으면 됩니다.

여기서 시작

두 가지 명령어.

npm i -g fimemory
fimemory setup

첫 번째 명령이 EACCES: permission denied로 실패하면(macOS에서 npm의 기본 전역 폴더가 root 소유인 경우 흔함), npm에 사용자 소유 폴더를 지정하고 다시 시도하세요. sudo는 필요 없습니다:

npm config set prefix ~/.npm-global
echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.zshrc && source ~/.zshrc
npm i -g fimemory

그런 다음 이미 실행 중이던 AI 도구를 모두 닫고 다시 여세요. 도구는 시작할 때 설정을 읽기 때문입니다.

이것이 설치의 전부입니다. setup은 저장소가 없으면 생성하고, 이 머신에서 찾은 모든 AI 도구를 연결한 다음, 자체 작업을 확인하고 무엇이 적용되었고 무엇이 적용되지 않았는지 출력합니다. 다시 실행해도 안전하고 지루합니다. 이미 준비된 것은 모두 unchanged로 보고되며 다시 쓰이지 않습니다. 작동했는지 확실하지 않을 때 다시 실행하세요.

터미널에서 저장소를 만들 때 setup은 암호화 과정을 안내합니다. 암호를 선택하고(또는 --plaintext로 건너뛰기 위해 키 하나를 누르면), 24단어 복구 문구를 한 번 출력하고 적어 두었는지 확인한 다음, 저장소를 이 머신에서 약 8시간 동안 잠금 해제 상태로 둡니다. 스크립트나 CI에서는 프롬프트가 없습니다. --passphrase "..."를 전달하거나 GESTALT_PASSPHRASE를 설정하거나 --plaintext를 지정하세요. 이 중 아무것도 없으면 추측하지 않고 깔끔하게 거부합니다. 암호와 24단어 문구를 모두 잃으면 데이터는 설계상 사라집니다. 이것이 "우리 서버가 아닌 당신의 키"의 대가이며, 안내 실행은 조용히 그렇게 되지 않도록 합니다.

setup이 대신 완료할 수 없는 한 단계는 자체 구성 파일을 관리하는 Claude Code입니다. setup은 이 머신에 claude 명령이 있는지 확인합니다. 있으면 붙여넣을 claude mcp add 한 줄을 출력합니다. 없으면(VSCode 확장과 데스크톱 앱은 명령줄을 설치하지 않음) 정확한 JSON 블록과 넣을 파일을 대신 출력합니다. 어느 쪽이든 "다음 단계" 아래에 표시되며 지나치지 않습니다.

단계가 실패하면 실행은 계속되고 실패는 자체 줄로 표시됩니다. 해당 줄을 수정하고 fimemory setup을 다시 실행하면 이미 성공한 단계는 그대로 유지됩니다.

나중에 필요할 세 가지 명령:

• fimemory onboard는 setup 이후 첫 단계를 안내합니다. 첫 번째 제안된 편집을 승인하는 과정을 안내하고, 작업 방식에 대한 세 가지 질문을 하고 답을 저장소에 기록한 다음, 자신의 사실로 답하는 검색을 보여줍니다. 아무것도 없는 연결된 저장소는 아무것도 없어도 고장난 것처럼 느껴집니다. 이 명령이 가장 짧은 해결책입니다.

• fimemory doctor는 전체 설정을 다시 읽고 무엇이 누락되었고 무엇을 해야 하는지 평이한 말로 알려줍니다. 반쯤 완성된 설치가 가장 흔한 실패 원인입니다.

• fimemory setup --plaintext는 암호화되지 않은 저장소로 동일한 설치를 수행합니다. 모든 파일은 텍스트 편집기에서 읽을 수 있으며, 폴더에 접근할 수 있는 사람이나 프로그램도 읽을 수 있습니다. 숨겨진 다운그레이드가 아니라 명확히 명시된 실제 선택입니다. 일반 텍스트로 시작한 저장소는 나중에 fimemory encrypt로 암호화를 채택할 수 있습니다(실제 콘텐츠가 쌓이기 전이 가장 저렴합니다).

이전에는 작동하는 설치와 죽은 설치가 동일해 보였습니다. 이제 설치가 어떤 상태인지 알려줍니다.

Related MCP server: Munin Memory

정직한 기대

• Windows, macOS, Linux에서 사람이 설치하고 사용함. 러너 주장이 아닙니다. 실제 머신에서 수동 설치 후 실제 작업을 수행했으며, 두 가지 다른 AI 도구가 한 저장소를 매일 읽고 쓰는 것을 수개월 동안 확인했습니다. Windows와 Mac은 각각 Claude Code와 Grok을 실행하고, Linux는 헤드리스로 실행합니다. CI는 또한 Linux와 macOS 러너에서 패키지를 빌드, 타입체크, 테스트, 전역 설치합니다. 그래도 여전히 다루지 못하는 것은 호스트 앱의 긴 꼬리입니다. 러너에는 데스크톱 세션이 없으므로 아래에 명명된 클라이언트 외에는 setup이 작성한 구성이 실제로 로드되는지 확인하지 못했습니다. Linux에서 클립보드 명령은 xclip 또는 Wayland의 wl-clipboard가 필요하며, 둘 다 기본 설치되지 않습니다. 문제가 보이면 fimemory doctor를 실행하고 보고해 주세요.

• 기억하지 않는 것보다 저렴하지 않습니다. 작은 프리미엄에 정확하며, 모든 것을 붙여넣는 것보다 훨씬 저렴합니다.

• 에이전트는 연결되고 지시받았을 때 읽습니다. setup은 MCP 구성, 규칙 텍스트, 검색 훅을 작성하지만, 어떤 메모리 제품도 호스트가 매 턴마다 자발적으로 참조하도록 강제할 수 없습니다.

• 자동 동기화는 제공되지 않습니다. 다중 머신은 사용자 계정의 자체 git 원격을 통해 작동합니다. Sync 서비스는 아직 없으므로, 직접 원격을 구성하지 않는 한 작성한 내용이 머신을 떠나지 않습니다.

• 제공 범위는 여러 에이전트가 있는 사용자 머신입니다. 두 머신을 하나의 개인 git 원격에 연결하세요: 두 번째 머신에서 fimemory join <url>을 실행한 다음 세션 전후에 fimemory pull을 실행하세요. 같은 노트에 대한 편집은 조용히 병합되지 않습니다. 지는 쪽은 검토할 보류 제안이 됩니다. 자체 원격을 넘어서는 팀 기능은 포함되지 않습니다.

setup이 실제로 실행하는 것

다섯 단계, 순서대로:

1. init — ~/.fimemory에 저장소가 없을 때만 실행됩니다(이전 설치의 기존 ~/.gestalt는 감지되어 유지됩니다). 이미 있으면 건너뛰고 절대 덮어쓰지 않습니다.

2. install-mcp — 찾은 각 호스트 구성 파일에 MCP 서버 항목을 작성합니다. 이것이 어시스턴트가 저장소를 읽을 수 있게 하는 것입니다.

3. install-hooks — Claude Code의 검색 훅을 ~/.claude/settings.json에 작성합니다. ~/.claude가 없으면 건너뜁니다.

4. install-rules — 각 호스트의 규칙 파일에 메모리 규칙 블록을 작성합니다. 이것이 어시스턴트가 실제로 저장소를 사용하게 하는 것입니다.

5. doctor — 모든 것을 다시 읽고 보고합니다.

훅은 의도적으로 규칙보다 먼저 실행됩니다. shim 규칙 텍스트는 관련 노트가 이미 턴에 포함되어 있을 수 있다고 모델에 알려줍니다. 이 문장은 훅이 설치된 후에만 참이므로 훅이 먼저 실행되고 그 결과가 문구를 결정합니다: 훅이 설치되면 Claude Code는 shim 문구를 받고, 훅이 건너뛰면 모든 호스트는 무조건 참인 검색 우선 문구를 받습니다. 훅 없이 shim 문구를 작성하면 모델이 도착하지 않는 주입을 위해 검색을 중단하라고 지시하는 것이며, 아무것도 하지 않는 것보다 나쁩니다.

모든 단계는 실패가 해당 단계의 줄이 되고 실행이 계속되도록 래핑됩니다. 쓸 수 없는 규칙 파일이 MCP 등록을 희생하게 해서는 안 되며, 둘 다 doctor 판정을 희생하게 해서도 안 됩니다. setup은 잠긴 암호화 저장소에서도 실행되며, 이는 두 번째 머신에서 일반적인 경우이며 doctor가 잠금을 보고할 수 있게 합니다.

개별 동사는 여전히 존재하며 독립적으로 작동합니다: init, install-mcp, install-hooks, install-rules, doctor.

어떤 도구가 무엇을 받는지

* 공급업체 문서화, 디스크에서 미검증. Windsurf, Cursor, Claude Desktop은 확인한 어떤 머신에도 설치되지 않았으므로 이러한 경로가 존재하는지 본 적이 없습니다. setup이 installed라고 말한 후 하나가 저장소를 무시하면 가장 먼저 의심할 것: 앱 자체 설정에서 규칙을 실제로 저장하는 위치를 확인하고 fimemory install-rules --file <path>를 다시 실행하세요. 표의 다른 모든 행은 디스크에서 확인되었습니다.

• Claude Code는 install-mcp가 작성하지 않는 유일한 호스트입니다. Claude Code CLI가 ~/.claude.json의 스키마를 소유하므로 claude mcp add fimemory -s user -- ...를 출력합니다. 규칙 블록과 훅은 자동으로 작성됩니다.

• Cursor: Cursor 규칙 파일을 작성하지 않습니다. Cursor가 사용자 수준 규칙을 어디에 저장하는지, ~/.cursor/rules를 로드하는지 여부는 미검증입니다. Cursor는 우리가 확인한 어떤 머신에도 설치되어 있지 않으며 이 디스크에 Cursor 문서도 없습니다. 이 페이지의 이전 버전은 이러한 한계를 사실로 명시했지만, 소스에서 읽은 적이 없었으며 아래 ~/.grok/GROK.md와 같은 실수이므로 제거되었습니다. 제3자 증거는 반대 방향을 가리킵니다: Grok의 자체 12-project-rules.md는 ~/.cursor/rules/를 스캔하는 규칙 디렉토리로 나열합니다. Cursor가 읽는 파일을 알고 있다면 install-rules --file <path>가 동일한 블록을 거기에 작성합니다.

• Claude Desktop: Claude Desktop 규칙 파일을 작성하지 않습니다. 디스크에 규칙 파일이 있는지 여부는 미검증입니다. 우리가 확인한 어떤 머신에도 설치되어 있지 않습니다. MCP 구성은 작성됩니다.

• Gemini CLI는 ~/.gemini/settings.json의 contextFileName으로 컨텍스트 파일 이름을 바꿀 수 있습니다. install-rules는 이를 읽고 존중하므로 블록은 Gemini가 실제로 읽는 파일에 배치됩니다.

• 그 외 모든 것, 우리가 들어본 적 없는 호스트 포함: install-mcp는 해당 클라이언트의 자체 구성에 붙여넣을 일반 JSON 스니펫을 출력합니다.

사람이 종단 간 검증: Claude Code와 Grok, Windows 11 및 macOS에서. 이 조합이 실제 작업에 매일 공유 저장소에 대해 설치되고 사용된 것입니다. 표의 다른 모든 호스트는 구성과 규칙이 작성됩니다. 정직한 호스트별 매트릭스는 측정된 대로 제공되며, 그 전에는 제공되지 않습니다.

호스트가 특이한 위치에 있다면: install-rules, install-mcp, doctor 모두 CODEX_HOME, GEMINI_CLI_HOME, GROK_HOME이 설정되면 이를 따르므로 세 가지 모두 호스트 위치에 대해 일치합니다. Claude Desktop의 구성 경로는 플랫폼(및 Windows의 APPDATA)에 따라 다릅니다. 나머지 경로인 Cursor와 Windsurf의 경로는 고정입니다.

훅, 정확히

install-hooks는 정확히 하나의 파일을 작성합니다: Claude Code의 ~/.claude/settings.json. 이것은 이 소프트웨어에 대한 진술입니다. 다른 도구에 훅이 없다는 주장이 아니며, 그 주장을 한 이 문장의 버전은 2026-07-31에 확인되었고 거짓이었습니다.

Grok CLI — 2026-07-31에 디스크의 grok 0.2.117을 직접 확인했습니다. Grok은 기본적으로 ~/.claude/settings.json에서 훅을 스캔합니다([compat.claude] hooks = true, ~/.grok/docs/user-guide/05-configuration.md에 문서화되어 있으며, 10-hooks.md의 Hook Locations 표에는 해당 파일이 전역 항상 신뢰되는 소스로 나열되어 있습니다). Grok은 우리의 두 핸들러를 로드합니다. 그러나 두 가지 독립적인 이유로 인젝션을 전달할 수 없습니다:

1. Grok은 훅의 stdout을 버립니다. 이것이 중요한 이유입니다. 우회할 수 없기 때문입니다. 우리가 측정했습니다: 네 가지 출력 형태(Claude의 hookSpecificOutput, 최상위 additionalContext, 일반 텍스트, systemMessage) 각각이 마커 파일을 통해 실제로 실행되었음을 확인했고, 각각 주입된 컨텍스트를 생성하지 않았으며, 하네스가 주입된 컨텍스트를 전혀 표면화할 수 있음을 증명한 양성 대조군과 대조되었습니다. 헤드리스 -p 모드에서 측정했으며, 대화형 TUI는 측정하지 않았습니다. Grok의 자체 문서도 이 문제를 확정하지 않습니다. 10-hooks.md는 PreToolUse와 중지 이벤트만 결정할 수 있고 "다른 모든 이벤트는 수동적"이라고 말하며, Passive Hooks 섹션은 SessionStart 또는 PostToolUse와 같은 이벤트에 대해 stdout이 무시된다고 말하지만, UserPromptSubmit를 지칭하는 예시가 아니라 문서가 아니라 실험이 여기서 권위자입니다.

2. 핸들러 형식에 args 필드가 없습니다. 10-hooks.md의 Key Fields 표에는 type, command, url, timeout, env가 열거되어 있으며, 우리의 전체 호출은 args에 있습니다. Grok은 인수 없이 인터프리터를 실행하며 해당 프로세스는 즉시 종료됩니다. command가 인라인 셸 명령을 허용하므로 수정 가능해 보이지만, 수정해도 훅이 실행될 뿐입니다. (1) 때문에 여전히 아무것도 주입하지 않습니다.

어느 쪽이든 차단되는 것은 없습니다: Grok은 오픈 실패(fail open)입니다. 그러나 "오픈 실패"는 "조용함"이 아닙니다. 10-hooks.md는 모든 훅 실패가 UI 스크롤백에 기록된다고 말하므로, 모든 Grok 프롬프트에서 훅 실패 줄이 표시됩니다. 이를 없애려면 ~/.grok/config.toml에서 [compat.claude] hooks = false로 설정하세요. ~/.claude/settings.json에서 핸들러를 삭제하지 마십시오. 그 파일은 Claude Code가 실제로 사용하는 파일이며, 거기서 제거하면 훅이 작동하는 유일한 호스트가 꺼집니다.

Grok은 ~/.claude/CLAUDE.md도 읽습니다. 규칙 파일은 해당 디렉터리가 있는 호스트 전용이 아닙니다. Grok의 12-project-rules.md는 Claude 호환성이 켜져 있을 때(기본값) 홈 레벨 ~/.claude/에서 CLAUDE.md 등을 스캔한다고 말하며, 실제 머신에서 grok inspect --json이 정확히 그 파일을 나열했습니다. 따라서 Claude Code + Grok 머신에서 "Claude Code용"으로 작성된 심 워딩이 Grok에도 도달하고 있었습니다. 이제는 그렇지 않습니다: 훅을 실행할 수 없는 감지된 호스트가 규칙 파일을 공유할 때, 해당 파일은 누가 명목상 소유하든 검색 우선 워딩을 받습니다. fimemory doctor는 각 규칙 파일이 어떤 본문을 담고 있는지 보고하며, 단지 블록이 있다는 것만 보고하지 않습니다.

Codex CLI에는 훅이 있습니다. 배포된 바이너리 @openai/codex 0.145.0(2026-08-01)에서 읽은 내용: 이벤트 집합에는 user_prompt_submit, session_start, pre_tool_use, stop이 포함되며, 바이너리에는 hooks/src/events/ 소스 경로와 hooks/hooks.json 로더가 포함되어 있습니다. 우리는 Codex 훅 구성을 작성하지 않으므로 우리의 훅은 거기서 실행되지 않습니다. 우리의 핸들러가 Codex에서 작동할지 — 즉 핸들러 스키마와 user_prompt_submit 훅의 stdout이 주입되는지 여부는 미검증이며, 어느 방향으로도 주장하지 않습니다.

Gemini CLI에는 훅이 있으며, 우리가 작성하는 바로 그 파일의 퍼스트파티 가져오기를 제공합니다. @google/gemini-cli 0.52.0(2026-08-01)에서 읽은 내용: UserPromptSubmit는 Gemini의 BeforeAgent 이벤트에 매핑되며, gemini hooks migrate는 <cwd>/.claude/settings.json을 읽고 해당 훅을 가져옵니다. 해당 명령을 사용할 때 한 가지 경고: 가져오기는 command, type, timeout만 복사하고 Grok과 정확히 동일하게 args를 버립니다. 우리의 핸들러가 포함된 .claude/settings.json이 있는 디렉터리에서 실행하면 모든 프롬프트에서 실패하는 node 프로세스가 생성됩니다. 우리는 Gemini 훅 구성을 작성하지 않으므로 이는 직접 마이그레이션을 실행하는 경우에만 발생합니다.

Windsurf 및 Claude Desktop: 훅을 지원하는지 여부는 미검증입니다. 둘 다 우리가 확인한 어떤 머신에도 설치되어 있지 않습니다. 우리는 둘 중 어느 것에도 훅 구성을 작성하지 않으며, 그 이상의 제한을 주장하지 않습니다.

Cursor: Grok의 문서에는 Cursor 훅 파일(~/.cursor/hooks.json)이 기록되어 있습니다. 우리는 이를 작성하지 않으며 우리의 핸들러를 이에 대해 테스트하지 않았습니다.

fimemory install-rules --list-hosts는 사용자 머신에 대한 이 모든 정보를 출력합니다: 감지된 호스트, 각 호스트가 규칙 파일을 보관하는 위치, 소스가 포함된 호스트별 훅 사유.

규칙 블록이 중요한 부분인 이유

install-mcp는 어시스턴트에게 저장소를 읽을 수 있는 능력을 제공합니다. install-rules --mode shim은 프롬프트 앞에 관련 메모를 주입하여 어시스턴트가 요청 없이 저장소를 읽게 만드는 것입니다. 우리의 자체 측정에서 이는 어시스턴트가 도구 호출을 통해 저장소를 검색하게 하는 비용의 일부에 불과합니다. 이것이 없으면 도구는 존재하지만 대부분 유휴 상태입니다.

심 워딩은 검색 훅이 실제로 실행되는 호스트에서 독점적으로 읽히는 파일에만 작성됩니다. 현재로서는 Grok CLI가 없는 머신의 Claude Code를 의미합니다. 다른 모든 파일은 검색 우선 블록을 대신 받습니다. 이는 해당 어시스턴트에게 아무것도 주입되지 않으므로 스스로 fimemory_search를 호출하라고 지시하는 워딩입니다. Grok CLI를 설치하면 다음 setup에서 ~/.claude/CLAUDE.md가 검색 우선 워딩으로 되돌아갑니다. Grok도 해당 파일을 읽기 때문입니다.

문제가 있어 보일 때

fimemory doctor는 저장소 모드, 키 소스, 각 호스트 구성의 MCP 등록, 규칙 블록, 검색 훅, 카탈로그 인덱스 및 저장소가 마지막으로 읽힌 시점을 확인합니다. 누락된 항목과 해결 방법을 명시하고, 실제로 문제가 있을 때 0이 아닌 종료 코드로 종료합니다. 인덱스가 없거나 디스크에 있는 메모를 나열하지 않는 저장소는 경고가 아니라 실패입니다: 검색은 인덱스를 읽으므로, 맹목적인 인덱스는 어시스턴트가 조용히 아무것도 찾지 못함을 의미합니다.

저장 데이터 암호화(기본값)

새 저장소는 Argon2id 패스프레이즈 뒤의 XChaCha20-Poly1305로 봉인되며, 24단어 복구 문구가 생성 시 한 번 출력됩니다(fimemory encrypt는 이전 또는 --plaintext 저장소를 동일한 상태로 만듭니다). 패스프레이즈와 해당 문구를 모두 잃으면 데이터는 설계상 사라집니다. 계정도 재설정도 없으며,这正是 문구가 중요한 이유입니다.

도구는 GESTALT_PASSPHRASE로 저장소를 엽니다. 사용자 셸이 원하는 방식으로 설정하세요:

$env:GESTALT_PASSPHRASE = 'your passphrase here'          # PowerShell
set "GESTALT_PASSPHRASE=your passphrase here"             # cmd.exe
GESTALT_PASSPHRASE='your passphrase here' fimemory list   # macOS, Linux

한 번의 잠금 해제로 명령이 약 8시간 동안 빠르게 유지됩니다(sessionKeyCacheTtlHours, 0은 비활성화). fimemory lock은 이를 조기 종료합니다.

2일차의 진실 — 놀라지 않도록: 해당 창이 만료되고 환경에 패스프레이즈가 없으면 CLI 명령이 다시 묻고, MCP 도구는 모든 호출에 수정 방법을 명시하는 명확한 "저장소가 잠겨 있습니다" 오류로 응답하며(도구가 실행되는 곳에 GESTALT_PASSPHRASE를 설정하거나, 모든 터미널에서 fimemory unlock 실행; 실행 중인 서버는 재시작 없이 다음 호출에서 잠금 해제를 인식합니다), 프롬프트별 검색 훅은 프롬프트를 차단하지 않고 조용히 유지됩니다. fimemory doctor가 바로 그 상태를 소리 내어 명명하는 도구입니다. GUI 앱(Claude Desktop 등)은 셸 프로필이 아닌 OS 사용자 환경을 읽으므로, 데스크톱 세션이 볼 수 있는 곳에 변수를 두세요.

경계에 대한 정직성: 저장소가 잠금 해제되면 연결된 MCP 클라이언트는 파일시스템 도구와 동등한 읽기 권한을 갖습니다. 이는 모든 메모리 MCP에 해당하는 사실이며, 우리는 이를 명확히 말합니다.

제거

레이어당 하나의 명령이며, 각 명령은 설치 프로그램이 작성한 것만 건드립니다:

fimemory uninstall-mcp      # remove the MCP entry from every host config
fimemory uninstall-rules    # remove the memory rule block, nothing else in the file
fimemory uninstall-hooks    # remove our two handlers from Claude Code's settings

아직 단일 철거 동사는 없으므로 uninstall-mcp는 다른 두 명령을 출력하고 전체 롤백이 한 화면에 유지됩니다.

uninstall-mcp는 빈 치환을 가진 install-mcp와 동일한 스캔입니다: 동일한 호스트, 동일한 파일, 호스트의 구성 디렉터리가 설치 여부를 결정한다는 동일한 규칙. 우리의 항목을 삭제하고 다른 것은 건드리지 않습니다. 파싱할 수 없는 구성은 거부되고 다시 쓰지 않고 바이트 단위로 동일하게 유지되며, 거부는 종료 코드 1이므로 fimemory uninstall-mcp && rm -rf ~/.fimemory는 계속하지 않고 중지됩니다. 우리의 것이 전혀 없는 호스트는 성공이며 종료 코드 0입니다.

Claude Code는 설치와 대칭입니다: claude mcp remove fimemory -s user를 출력하고 ~/.claude.json을 읽기 전용으로 읽어 항목이 등록되어 있는지 여부만 알려줍니다.

아무것도 제거하기 전에 — 패스프레이즈 순서

install-mcp --env-passthrough GESTALT_PASSPHRASE를 실행한 적이 있다면, 암호화된 저장소의 패스프레이즈가 해당 호스트 구성 파일에 일반 텍스트로 있습니다. 우리의 항목을 제거하면 항목과 함께 삭제되며, 일부 사람들에게는 해당 구성 파일이 존재하는 유일한 사본입니다. 따라서 순서는 양방향으로 중요합니다:

• 저장소 유지: 무엇이든 제거하기 전에 기억하는 패스프레이즈 또는 24단어 복구 문구로 여전히 열 수 있는지 확인하세요. 먼저 fimemory uninstall-mcp --dry-run을 실행하세요. 제거할 환경 변수의 이름을 명시하며 값은 절대 표시하지 않고 아무것도 작성하지 않습니다.

• 저장소 폐기: 먼저 구성을 제거한 다음 저장소 폴더를 제거하세요. 이 순서가 올바르며 구성 파일에 패스프레이즈가 남지 않습니다.

• Claude Code의 자체 바이너리는 claude mcp remove가 env 변수와 헤더를 포함한 서버 구성을 영구적으로 삭제한다고 명시하므로, 출력된 명령도 해당 값을 함께 가져갑니다.

저장소 자체는 사용자의 폴더이므로 제거는 디렉터리 제거입니다: ~/.fimemory(이름 변경 이전 설치의 경우 ~/.gestalt), 또는 --home으로 지정한 위치. 메모를 유지하려면 먼저 내보내세요.

사용자의 파일, 사용자의 출구

fimemory export --plaintext <dir>는 모든 메모, 로그 및 제안된 편집을 저장소 외부에 일반 Markdown으로 작성합니다. 탈출구는 실제이며 첫날부터 작동합니다.

명명 참고

사용자 대면의 모든 것은 fimemory입니다: 명령, MCP 서버 키, 도구 ID(fimemory_search, fimemory_get, ...). 이름 변경 이전의 설치는 계속 작동합니다: ~/.gestalt의 저장소, GESTALT_* 환경 변수, 이전 gestalt MCP 항목이 모두 여전히 감지되고 존중됩니다.

라이선스

FSL-1.1-ALv2에 따라 소스 사용 가능( LICENSE.md 참조). 무료로 사용 및 수정할 수 있습니다. 판매하거나 경쟁 서비스로 운영할 수 없습니다. 각 버전은 출시 2년 후 Apache-2.0이 됩니다.