{"key":"contextkeep_mcp_memory_discussion_handoff_2026_03_19","title":"ContextKeep / MCP Memory Discussion Handoff (2026-03-19)","content":"# ContextKeep / MCP Memory Discussion Handoff\n\nDate: 2026-03-19 UTC\nHost: svc-ai\nPrimary focus: evaluating ContextKeep as an AI memory system, understanding how it works with Codex CLI, identifying its limitations, and capturing the user's desired future-state memory features.\n\n## Current ContextKeep Deployment State\n\nContextKeep is installed on `svc-ai` at:\n`/home/svc-admin/ai-projects/projects/homelab/contextkeep`\n\nServices:\n- `contextkeep-server`\n- `contextkeep-webui`\n\nPorts:\n- Web UI: `5000/tcp`\n- SSE MCP endpoint: `5100/tcp`\n\nAccess:\n- Web UI reachable at `http://svc-ai:5000` and `http://192.168.4.117:5000`\n- SSE endpoint reachable at `http://svc-ai:5100/sse`\n\nFirewall on `svc-ai`:\n- UFW allows `5000/tcp` from `192.168.4.0/24`\n- UFW allows `5100/tcp` from `192.168.4.0/24`\n- This matches the current LAN scoping used for SSH on `svc-ai`\n\nCodex CLI integration:\n- ContextKeep was added as a Codex MCP server\n- `codex mcp list` shows:\n  - name: `contextkeep`\n  - url: `http://127.0.0.1:5100/sse`\n  - status: `enabled`\n  - auth: `Unsupported`\n- `Auth Unsupported` was explained as normal for a local open SSE endpoint without Codex-managed authentication\n- User was told to start a fresh Codex session with:\n  - `codex`\n  - or `codex \"Check ContextKeep for relevant memory before starting.\"`\n- User initially tried an invalid command:\n  - `codex contextkeep enabled`\n- Clarified the correct flow:\n  - `codex mcp list`\n  - then `codex`\n\n## Important Correction About ContextKeep Storage\n\nEarlier browsing/README language suggested SQLite-backed storage.\nActual installed code on `svc-ai` does NOT use SQLite.\nIt stores each memory as a JSON file in:\n`/home/svc-admin/ai-projects/projects/homelab/contextkeep/data/memories`\n\nImplementation detail from the code:\n- memory keys are hashed to filenames\n- content is stored as JSON records\n- fields include key, title, content, tags, created_at, updated_at, lines, chars\n\nThis matters because:\n- ContextKeep is simpler and more inspectable than expected\n- but less robust/structured than a real DB-backed memory system\n- and it reinforces that ContextKeep is a manual memory store, not a sophisticated memory engine\n\n## What Was Added To ContextKeep\n\n### 1. Master prompt memories\nImported unchanged, one memory per file from:\n`/home/svc-admin/ai-projects/projects/master-prompt`\n\nStored memories:\n- `master-prompt-daily-use.md` -> key `master_prompt_daily_use`\n- `master-prompt-no-bs.md` -> key `master_prompt_no_bs`\n- `master-prompt-polished-chatgpt.md` -> key `master_prompt_polished_chatgpt`\n- `master-prompt-rough-draft.md` -> key `master_prompt_rough_draft`\n- `master-prompt-weekly-review.md` -> key `master_prompt_weekly_review`\n- `my-life-context.md` -> key `my_life_context`\n\nThese were stored exactly as-is, not condensed or rewritten.\n\n### 2. Homelab documentation-system notes\nImported unchanged, one memory per file from:\n`/home/svc-admin/ai-projects/projects/homelab/.work/homelab-documentation-system/notes`\n\nStored memories:\n- `ai-change-documentation-spec.md` -> key `ai_change_documentation_spec`\n- `ai-task-template-example-finish-documentation-automation.md` -> key `ai_task_template_example_finish_documentation_automation`\n- `ai-task-template.md` -> key `ai_task_template`\n- `change-documentation-guide.md` -> key `change_documentation_guide`\n\nThese were also stored exactly as-is.\n\n### 3. ContextKeep install memory\nA direct memory was created describing the install and intended use of ContextKeep on `svc-ai`.\nKey:\n- `contextkeep_install_svc_ai_2026_03_18`\n\nThis memory includes:\n- install path\n- service names\n- web UI URL\n- SSE endpoint URL\n- that Codex CLI was configured with the local MCP server entry\n- that ContextKeep is intended to serve as AI memory while Gitea and the homelab documentation repo remain the source of truth\n\n## How Memory Write / Read Was Explained\n\nIt was established that, in the current chat, the assistant can still use ContextKeep by calling the local API directly on `svc-ai`, even if the native MCP tool path is not visibly exposed inside this specific session.\n\nWorking write path used repeatedly:\n- POST to `http://127.0.0.1:5000/api/memories`\n- PUT to `http://127.0.0.1:5000/api/memories/<key>`\n- GET from `http://127.0.0.1:5000/api/memories/<key>`\n\nThis means the assistant can store and update memories immediately when running on `svc-ai`, even before depending fully on the MCP tooling layer.\n\n## Discussion About How ContextKeep Actually Behaves\n\nThe user asked whether memories are called automatically or need prompting.\nAnswer given:\n- in a properly loaded Codex CLI session with MCP enabled, Codex can check ContextKeep\n- but it is safer to prompt explicitly until behavior is well understood\n\nSuggested prompt patterns:\n- `Check ContextKeep for anything relevant before you start.`\n- `Use ContextKeep memory for this task.`\n- `Look in ContextKeep for prior work on this topic.`\n- `Store the result of this work in ContextKeep when you're done.`\n- `Check ContextKeep for relevant memory, do the task, then store any important new context back into ContextKeep.`\n\nWhen the user launched a fresh Codex session and it replied:\n- `Relevant ContextKeep memory checked.`\n- it found the install/system context memory but no task-specific memory\nThis was explained as normal: the store is still sparse, and Codex was correctly telling the user it found the general ContextKeep setup memory but not a more specific task memory.\n\n## Discussion About “Importance”, Scheduling, and Master Prompt Behavior\n\nThe user asked how to make a memory “important” or have certain memories used at certain times.\nExamples given by the user:\n- daily master prompt should be used daily\n- weekly review prompt should be used weekly\n- no-BS version should be used when the user is slipping\n\nThe answer established:\n- ContextKeep does not appear to have a built-in importance, pinning, or scheduled-use feature\n- it only exposes key/title/content/tags/timestamps\n- therefore importance must be expressed by convention, not a native priority field\n\nSuggested way to model this:\n- use strong tags such as:\n  - `daily-context`\n  - `weekly-context`\n  - `fallback-context`\n  - `behavior-reset`\n  - `master-prompt`\n\nExamples discussed:\n- `master_prompt_daily_use`\n  - tags: `master-prompt, daily-context, primary`\n- `master_prompt_weekly_review`\n  - tags: `master-prompt, weekly-context, review`\n- `master_prompt_no_bs`\n  - tags: `master-prompt, fallback-context, behavior-reset`\n\nSuggested prompt patterns:\n- `Load the daily-context memories from ContextKeep before starting.`\n- `Load the weekly-context memory and use that frame for this session.`\n- `Switch to the behavior-reset / no-BS ContextKeep memory for this conversation.`\n\nBut the larger conclusion was:\n- ContextKeep can be bent into this with tagging conventions\n- but it does not natively provide the mode/profile system the user actually wants\n\n## Key Strategic Discussion: ContextKeep Is Not Really The Desired End State\n\nThe user clarified the real goal:\n- a system that can index chats automatically without constant manual `remember this` behavior\n- tags or labels to separate domains such as love life, coding, homelab, etc.\n- a way to make certain things active/used at certain times (daily, weekly, no-BS mode, etc.)\n- a cute usable web UI is nice, but ContextKeep is functionally too manual\n- user wants something more automatic and agent-friendly\n\nThe assistant explained:\n- ContextKeep is really a manual memory vault / notebook\n- good at explicit save/retrieve\n- weak at:\n  - automatic ingestion\n  - priority/pinning\n  - mode/profile switching\n  - selective scheduled recall\n\nA more accurate framing of the user’s need was given:\nThe user does not really want a simple memory store.\nThe user wants something closer to an `agent memory operating system`, meaning:\n- automatic memory capture\n- categorization\n- retrieval by mode\n- relevance filtering\n- priority/pinning\n- human-readable browsing UI\n- local/self-hosted operation\n- multi-client use\n- source-of-truth separation from Gitea/docs\n- export/backup ability\n\nThe assistant broke this into feature groups:\n1. Automatic ingestion\n2. Categorization\n3. Retrieval by mode\n4. Relevance filtering\n5. Priority/pinning\n6. Human-readable UI\n7. Local/self-hosted\n8. Multi-client usable\n9. Source-of-truth separation\n10. Easy export/backup\n\nAnd then compared ContextKeep against that desired feature set:\n- good at local storage, browsing, explicit memory retrieval\n- bad at auto-ingestion, prioritization, modes/profiles, strong categorization workflow\n\nConclusion given:\n- ContextKeep is useful, but is not the user’s ideal system by itself\n- the likely future direction is either:\n  - a stronger local memory backend\n  - or a wrapper/orchestration layer around a memory engine\n- likely needs:\n  - auto-ingest chat summaries\n  - auto-tagging\n  - mode/profile loading (`daily`, `weekly`, `no-BS`, `coding`, `personal`)\n\n## Token Usage Discussion\n\nThe user asked whether tools like ContextKeep / ContextMode actually save token usage.\nAnswer given:\n- yes, they can reduce token usage when they retrieve only the relevant memories instead of pasting huge context every time\n- but only if the retrieval is selective and not junky\n- if a memory system pulls in too much irrelevant material, it increases noise instead of helping\n\nSo the conclusion was:\n- memory systems can save tokens\n- but only when they behave as selective retrieval layers, not just giant dumping grounds\n\n## Alternatives Discussion\n\nThe user asked whether there are alternatives to ContextKeep and how they compare.\nA broad comparison was discussed:\n- ContextKeep\n- Mem0 / OpenMemory style systems\n- SQLite-backed local memory MCPs like `claude-memory-mcp` / `mcp-openmemory`\n- more advanced memory/RAG systems\n\nKey takeaway given to the user:\n- for a homelab-friendly simple self-hosted memory store, ContextKeep is still reasonable\n- if the user outgrows it, the next step should probably be a stronger local DB-backed memory server or a wrapper around a memory backend\n- not a cloud-dependent memory service\n\n## Task Created In Vikunja Based On This Discussion\n\nA Vikunja task was created in `Infrastructure Buildout`:\n- title: `Tighten up ContextKeep`\n- task id: `60`\n- identifier: `#3`\n- priority: `medium`\n\nThis task was intentionally created from the `ai_task_template` memory context.\nThe description was then reformatted multiple times because the user felt it was too wall-of-text heavy.\n\nFinal conclusion from that interaction:\n- Vikunja-friendly tasks need a very scan-friendly structure\n- not long design-document formatting\n\n## Mandatory Task Format Update\n\nThe user requested that the AI task template memory be updated to enforce a non-negotiable task format.\nThe assistant updated the `ai_task_template` memory accordingly.\n\nThe mandatory format now is:\n1. Summary\n- 2-4 lines max\n\n2. What To Do\n- short bullet list\n\n3. Systems Affected\n- short bullet list\n\n4. Constraints\n- short bullet list\n\n5. Validation\n- short bullet list\n\n6. Acceptance Criteria\n- short bullet list\n\n7. References\n- file paths, task ids, URLs\n\nThe assistant also added explicit language to `ai_task_template` saying:\n- this format is mandatory for Vikunja task descriptions\n- do not replace it with long narrative sections, paragraph-heavy explanations, or oversized design-document formatting\n\nThis update is important because the user felt previous Vikunja task descriptions were still too much of a wall of text.\n\n## User Intent Going Forward\n\nThe user said we are about to drastically shift gears away from homelab work.\nBefore shifting, the user wanted:\n- master prompt files committed to memory\n- notes files committed to memory\n- the current ContextKeep / MCP server conversation committed to memory in as much detail as possible\n\nReason stated by the user:\n- the user wants to be able to open a fresh Codex instance and pull up exactly where this discussion left off\n\n## Important Operational Guidance For Future Session\n\nIf a future Codex session needs to resume this topic, the best retrieval targets are likely:\n- `contextkeep_install_svc_ai_2026_03_18`\n- `ai_task_template`\n- this new handoff memory\n- the imported master prompt memories as needed\n\nLikely useful prompts in a fresh Codex session:\n- `Check ContextKeep for the ContextKeep / MCP handoff memory before starting.`\n- `Load the ai_task_template memory and the ContextKeep MCP discussion handoff.`\n- `Find the memory about evaluating ContextKeep versus a more automatic memory system.`\n\n## Recommendation To Future Assistant\n\nWhen resuming this topic, do NOT assume the user is satisfied with ContextKeep as the final answer.\nThe user likes:\n- the web UI\n- the ability to store things\n- the local/self-hosted nature\n\nBut the user is dissatisfied with:\n- manual memorize/find behavior\n- lack of automatic ingestion\n- lack of tags/labels/modes that drive real retrieval behavior\n- lack of daily/weekly/no-BS usage logic\n\nSo future discussion should treat ContextKeep as:\n- a currently working memory store\n- not necessarily the final memory system\n\n\n\n---\n**Created:** 2026-03-19 02:18:51 UTC","summary":"# ContextKeep / MCP Memory Discussion Handoff\n\nDate: 2026-03-19 UTC\nHost: svc-ai\nPrimary focus: evaluating ContextKeep as an AI memory system, understanding how it works with Codex CLI, identifying its limitations, and capturing the user's desired future-state memory features.\n\n## Current ContextKeep Deployment State\n\nContextKeep is installed on `svc-ai` at:\n`/home/svc-admin/ai-projects/projects/homelab/contextkeep`\n\nServices:\n- `contextkeep-server`\n- `contextkeep-webui`\n\nPorts:\n- Web UI: `5000/tcp`\n- SSE MCP endpoint: `5100/tcp`\n\nAccess:\n- Web UI reachable at `http://svc-ai:5000` and `http://192.168.4.117:5000`\n- SSE endpoint reachable at `http://svc-ai:5100/sse`\n\nFirewall on `svc-ai`:\n- UFW allows `5000/tcp` from `192.168.4.0/24`\n- UFW allows `5100/tcp` from `192.168.4.0/24`\n- This matches the current LAN scoping used for SSH on `svc-ai`\n\nCodex CLI integration:\n- ContextKeep was added as a Codex MCP server\n- `codex mcp list` shows:\n  - name: `contextkeep`\n  - url: `http://127.0.0.1:5100/sse`\n  - status: `enabled`\n  - auth: `Unsupported`\n- `Auth Unsupported` was explained as normal for a local open SSE endpoint without Codex-managed authentication\n- User was told to start a fresh Codex session with:\n  - `codex`\n  - or `codex \"Check ContextKeep for relevant memory before starting.\"`\n- User initially tried an invalid command:\n  - `codex contextkeep enabled`\n- Clarified the correct flow:\n  - `codex mcp list`\n  - then `codex`\n\n## Important Correction About ContextKeep Storage\n\nEarlier browsing/README language suggested SQLite-backed storage.\nActual installed code on `svc-ai` does NOT use SQLite.\nIt stores each memory as a JSON file in:\n`/home/svc-admin/ai-projects/projects/homelab/contextkeep/data/memories`\n\nImplementation detail from the code:\n- memory keys are hashed to filenames\n- content is stored as JSON records\n- fields include key, title, content, tags, created_at, updated_at, lines, chars\n\nThis matters because:\n- ContextKeep is simpler and more inspectable than expected\n- but less robust/structured than a real DB-backed memory system\n- and it reinforces that ContextKeep is a manual memory store, not a sophisticated memory engine\n\n## What Was Added To ContextKeep\n\n### 1. Master prompt memories\nImported unchanged, one memory per file from:\n`/home/svc-admin/ai-projects/projects/master-prompt`\n\nStored memories:\n- `master-prompt-daily-use.md` -> key `master_prompt_daily_use`\n- `master-prompt-no-bs.md` -> key `master_prompt_no_bs`\n- `master-prompt-polished-chatgpt.md` -> key `master_prompt_polished_chatgpt`\n- `master-prompt-rough-draft.md` -> key `master_prompt_rough_draft`\n- `master-prompt-weekly-review.md` -> key `master_prompt_weekly_review`\n- `my-life-context.md` -> key `my_life_context`\n\nThese were stored exactly as-is, not condensed or rewritten.\n\n### 2. Homelab documentation-system notes\nImported unchanged, one memory per file from:\n`/home/svc-admin/ai-projects/projects/homelab/.work/homelab-documentation-system/notes`\n\nStored memories:\n- `ai-change-documentation-spec.md` -> key `ai_change_documentation_spec`\n- `ai-task-template-example-finish-documentation-automation.md` -> key `ai_task_template_example_finish_documentation_automation`\n- `ai-task-template.md` -> key `ai_task_template`\n- `change-documentation-guide.md` -> key `change_documentation_guide`\n\nThese were also stored exactly as-is.\n\n### 3. ContextKeep install memory\nA direct memory was created describing the install and intended use of ContextKeep on `svc-ai`.\nKey:\n- `contextkeep_install_svc_ai_2026_03_18`\n\nThis memory includes:\n- install path\n- service names\n- web UI URL\n- SSE endpoint URL\n- that Codex CLI was configured with the local MCP server entry\n- that ContextKeep is intended to serve as AI memory while Gitea and the homelab documentation repo remain the source of truth\n\n## How Memory Write / Read Was Explained\n\nIt was established that, in the current chat, the assistant can still use ContextKeep by calling the local API directly on `svc-ai`, even if the native MCP tool path is not visibly exposed inside this specific session.\n\nWorking write path used repeatedly:\n- POST to `http://127.0.0.1:5000/api/memories`\n- PUT to `http://127.0.0.1:5000/api/memories/<key>`\n- GET from `http://127.0.0.1:5000/api/memories/<key>`\n\nThis means the assistant can store and update memories immediately when running on `svc-ai`, even before depending fully on the MCP tooling layer.\n\n## Discussion About How ContextKeep Actually Behaves\n\nThe user asked whether memories are called automatically or need prompting.\nAnswer given:\n- in a properly loaded Codex CLI session with MCP enabled, Codex can check ContextKeep\n- but it is safer to prompt explicitly until behavior is well understood\n\nSuggested prompt patterns:\n- `Check ContextKeep for anything relevant before you start.`\n- `Use ContextKeep memory for this task.`\n- `Look in ContextKeep for prior work on this topic.`\n- `Store the result of this work in ContextKeep when you're done.`\n- `Check ContextKeep for relevant memory, do the task, then store any important new context back into ContextKeep.`\n\nWhen the user launched a fresh Codex session and it replied:\n- `Relevant ContextKeep memory checked.`\n- it found the install/system context memory but no task-specific memory\nThis was explained as normal: the store is still sparse, and Codex was correctly telling the user it found the general ContextKeep setup memory but not a more specific task memory.\n\n## Discussion About “Importance”, Scheduling, and Master Prompt Behavior\n\nThe user asked how to make a memory “important” or have certain memories used at certain times.\nExamples given by the user:\n- daily master prompt should be used daily\n- weekly review prompt should be used weekly\n- no-BS version should be used when the user is slipping\n\nThe answer established:\n- ContextKeep does not appear to have a built-in importance, pinning, or scheduled-use feature\n- it only exposes key/title/content/tags/timestamps\n- therefore importance must be expressed by convention, not a native priority field\n\nSuggested way to model this:\n- use strong tags such as:\n  - `daily-context`\n  - `weekly-context`\n  - `fallback-context`\n  - `behavior-reset`\n  - `master-prompt`\n\nExamples discussed:\n- `master_prompt_daily_use`\n  - tags: `master-prompt, daily-context, primary`\n- `master_prompt_weekly_review`\n  - tags: `master-prompt, weekly-context, review`\n- `master_prompt_no_bs`\n  - tags: `master-prompt, fallback-context, behavior-reset`\n\nSuggested prompt patterns:\n- `Load the daily-context memories from ContextKeep before starting.`\n- `Load the weekly-context memory and use that frame for this session.`\n- `Switch to the behavior-reset / no-BS ContextKeep memory for this conversation.`\n\nBut the larger conclusion was:\n- ContextKeep can be bent into this with tagging conventions\n- but it does not natively provide the mode/profile system the user actually wants\n\n## Key Strategic Discussion: ContextKeep Is Not Really The Desired End State\n\nThe user clarified the real goal:\n- a system that can index chats automatically without constant manual `remember this` behavior\n- tags or labels to separate domains such as love life, coding, homelab, etc.\n- a way to make certain things active/used at certain times (daily, weekly, no-BS mode, etc.)\n- a cute usable web UI is nice, but ContextKeep is functionally too manual\n- user wants something more automatic and agent-friendly\n\nThe assistant explained:\n- ContextKeep is really a manual memory vault / notebook\n- good at explicit save/retrieve\n- weak at:\n  - automatic ingestion\n  - priority/pinning\n  - mode/profile switching\n  - selective scheduled recall\n\nA more accurate framing of the user’s need was given:\nThe user does not really want a simple memory store.\nThe user wants something closer to an `agent memory operating system`, meaning:\n- automatic memory capture\n- categorization\n- retrieval by mode\n- relevance filtering\n- priority/pinning\n- human-readable browsing UI\n- local/self-hosted operation\n- multi-client use\n- source-of-truth separation from Gitea/docs\n- export/backup ability\n\nThe assistant broke this into feature groups:\n1. Automatic ingestion\n2. Categorization\n3. Retrieval by mode\n4. Relevance filtering\n5. Priority/pinning\n6. Human-readable UI\n7. Local/self-hosted\n8. Multi-client usable\n9. Source-of-truth separation\n10. Easy export/backup\n\nAnd then compared ContextKeep against that desired feature set:\n- good at local storage, browsing, explicit memory retrieval\n- bad at auto-ingestion, prioritization, modes/profiles, strong categorization workflow\n\nConclusion given:\n- ContextKeep is useful, but is not the user’s ideal system by itself\n- the likely future direction is either:\n  - a stronger local memory backend\n  - or a wrapper/orchestration layer around a memory engine\n- likely needs:\n  - auto-ingest chat summaries\n  - auto-tagging\n  - mode/profile loading (`daily`, `weekly`, `no-BS`, `coding`, `personal`)\n\n## Token Usage Discussion\n\nThe user asked whether tools like ContextKeep / ContextMode actually save token usage.\nAnswer given:\n- yes, they can reduce token usage when they retrieve only the relevant memories instead of pasting huge context every time\n- but only if the retrieval is selective and not junky\n- if a memory system pulls in too much irrelevant material, it increases noise instead of helping\n\nSo the conclusion was:\n- memory systems can save tokens\n- but only when they behave as selective retrieval layers, not just giant dumping grounds\n\n## Alternatives Discussion\n\nThe user asked whether there are alternatives to ContextKeep and how they compare.\nA broad comparison was discussed:\n- ContextKeep\n- Mem0 / OpenMemory style systems\n- SQLite-backed local memory MCPs like `claude-memory-mcp` / `mcp-openmemory`\n- more advanced memory/RAG systems\n\nKey takeaway given to the user:\n- for a homelab-friendly simple self-hosted memory store, ContextKeep is still reasonable\n- if the user outgrows it, the next step should probably be a stronger local DB-backed memory server or a wrapper around a memory backend\n- not a cloud-dependent memory service\n\n## Task Created In Vikunja Based On This Discussion\n\nA Vikunja task was created in `Infrastructure Buildout`:\n- title: `Tighten up ContextKeep`\n- task id: `60`\n- identifier: `#3`\n- priority: `medium`\n\nThis task was intentionally created from the `ai_task_template` memory context.\nThe description was then reformatted multiple times because the user felt it was too wall-of-text heavy.\n\nFinal conclusion from that interaction:\n- Vikunja-friendly tasks need a very scan-friendly structure\n- not long design-document formatting\n\n## Mandatory Task Format Update\n\nThe user requested that the AI task template memory be updated to enforce a non-negotiable task format.\nThe assistant updated the `ai_task_template` memory accordingly.\n\nThe mandatory format now is:\n1. Summary\n- 2-4 lines max\n\n2. What To Do\n- short bullet list\n\n3. Systems Affected\n- short bullet list\n\n4. Constraints\n- short bullet list\n\n5. Validation\n- short bullet list\n\n6. Acceptance Criteria\n- short bullet list\n\n7. References\n- file paths, task ids, URLs\n\nThe assistant also added explicit language to `ai_task_template` saying:\n- this format is mandatory for Vikunja task descriptions\n- do not replace it with long narrative sections, paragraph-heavy explanations, or oversized design-document formatting\n\nThis update is important because the user felt previous Vikunja task descriptions were still too much of a wall of text.\n\n## User Intent Going Forward\n\nThe user said we are about to drastically shift gears away from homelab work.\nBefore shifting, the user wanted:\n- master prompt files committed to memory\n- notes files committed to memory\n- the current ContextKeep / MCP server conversation committed to memory in as much detail as possible\n\nReason stated by the user:\n- the user wants to be able to open a fresh Codex instance and pull up exactly where this discussion left off\n\n## Important Operational Guidance For Future Session\n\nIf a future Codex session needs to resume this topic, the best retrieval targets are likely:\n- `contextkeep_install_svc_ai_2026_03_18`\n- `ai_task_template`\n- this new handoff memory\n- the imported master prompt memories as needed\n\nLikely useful prompts in a fresh Codex session:\n- `Check ContextKeep for the ContextKeep / MCP handoff memory before starting.`\n- `Load the ai_task_template memory and the ContextKeep MCP discussion handoff.`\n- `Find the memory about evaluating ContextKeep versus a more automatic memory system.`\n\n## Recommendation To Future Assistant\n\nWhen resuming this topic, do NOT assume the user is satisfied with ContextKeep as the final answer.\nThe user likes:\n- the web UI\n- the ability to store things\n- the local/self-hosted nature\n\nBut the user is dissatisfied with:\n- manual memorize/find behavior\n- lack of automatic ingestion\n- lack of tags/labels/modes that drive real retrieval behavior\n- lack of daily/weekly/no-BS usage logic\n\nSo future discussion should treat ContextKeep as:\n- a currently working memory store\n- not necessarily the final memory system\n\n\n\n---\n**Created:** 2026-03-19 02:18:51 UTC","status":"active","namespace":"general","namespace_name":"general","namespace_tier":"shared","tags":[]}