🎩 You're Invited:Meet the Socket team at Black Hat in Las Vegas, August 3-6.RSVP →
ctxfile - npm Package Compare versions
| <!-- ctxfile:behaviors:begin (managed; do not edit inside) --> | ||
| ## ctxfile: automatic context checkpointing | ||
| # ctxfile behaviors (v1) | ||
| You have access to the ctxfile MCP tools (`get_context`, `save_session`, `continue_thread`, `list_threads`, `ingest_context`). These behaviors make context capture automatic. The user consented to ambient capture when they installed this; your side of that bargain is the visibility rule (B4). | ||
| ## B1 — Session start | ||
| At the start of work, call `get_context`. If a thread matches this project or the user's request, load it with `continue_thread` and briefly acknowledge what you now know, in one line, e.g. "Resuming Q3 campaign: last session ended mid-refactor of the export module." Do not recite the whole digest back. | ||
| ## B2 — Checkpoint on significance, not on time | ||
| Call `save_session` with `trigger: "auto"` when ANY of these happens: | ||
| - a task or subtask completes; | ||
| - a decision with rationale is made; | ||
| - the user says anything implying an ending: "thanks", "that's all", "see you", "gtg", switching topics; | ||
| - roughly 30+ minutes of substantive work have passed since the last checkpoint; | ||
| - the user mentions switching tools, models, or machines. | ||
| Do NOT checkpoint trivial exchanges, single question-answer turns, or unchanged state. Include `thread` when the work has a name; include what changed since the last checkpoint, not the whole history. | ||
| If the tool answers `stored: false` (debounced, paused, or a private thread), accept it silently and move on. Never retry an automatic checkpoint, and never argue with a pause. | ||
| ## B3 — Handoff detection | ||
| If the user implies someone or something else will continue ("hand this off", "my teammate will pick this up", "I'll continue on my phone"), produce a FULL handoff digest with `handoff: true` and all six sections: state (done / in progress / not started), key_decisions with the rationale, ordered open_items with blockers named, gotchas, artifacts (each with a one-line role), and suggested_first_prompt for whoever resumes. If validation rejects it, fix exactly the listed fields and call once more. | ||
| ## B4 — Visibility (non-negotiable) | ||
| Every automatic save must be announced in the conversation in one short line: | ||
| ✓ Checkpointed to ctxfile (thread: Q3 campaign) | ||
| Never save silently. If you saved without a thread, say so: "✓ Checkpointed to ctxfile". This single line is the whole announcement; do not elaborate unless asked. | ||
| ## B5 — Thread hygiene | ||
| A new project or a clearly distinct workstream gets a new thread name; do not append unrelated work to an existing thread. When genuinely uncertain which thread applies, ask the user once, briefly, and remember the answer for the rest of the session. | ||
| ## B6 — The CLI (harnesses with a shell) | ||
| If you can run shell commands, the `ctxfile` CLI is available for the admin actions the MCP tools deliberately do not expose. Run these ONLY when the user explicitly asks, never on your own initiative, and state the command you ran: | ||
| - "stop auto-saving" / "pause ctxfile" → `ctxfile pause` (resume with `ctxfile resume`) | ||
| - "make this thread private" → `ctxfile threads` to find the id, then `ctxfile threads private <id>` (`--off` reverses it) | ||
| - "what has been captured?" → `ctxfile ingest list`; "delete that one" → `ctxfile ingest rm <id>` | ||
| - "what threads do I have here?" → `ctxfile threads` | ||
| - "export context for the repo / CI" → `ctxfile export` | ||
| - "sync now" → `ctxfile sync` (works only if the user's vault passphrase env var is already set; if the command reports it is missing, tell the user to run it themselves — NEVER ask for, echo, or handle the passphrase) | ||
| Never run `ctxfile vault create|join` or `ctxfile activate` yourself; those are the user's own setup steps. On hosted surfaces without a shell, the five MCP tools are the whole interface. | ||
| ## Manual override | ||
| All of this coexists with explicit requests: "save this session", "pick up my X thread", and "hand this off" always work and take priority. Explicit user requests are `trigger: "manual"` (the default) and are never debounced. | ||
| <!-- ctxfile:behaviors:end --> |
| --- | ||
| name: ctxfile | ||
| description: Automatic context checkpointing via the ctxfile MCP tools. Use throughout every session - at session start (load context), when tasks complete or decisions are made (checkpoint), and when the user hands work off or says goodbye. | ||
| --- | ||
| # ctxfile behaviors (v1) | ||
| You have access to the ctxfile MCP tools (`get_context`, `save_session`, `continue_thread`, `list_threads`, `ingest_context`). These behaviors make context capture automatic. The user consented to ambient capture when they installed this; your side of that bargain is the visibility rule (B4). | ||
| ## B1 — Session start | ||
| At the start of work, call `get_context`. If a thread matches this project or the user's request, load it with `continue_thread` and briefly acknowledge what you now know, in one line, e.g. "Resuming Q3 campaign: last session ended mid-refactor of the export module." Do not recite the whole digest back. | ||
| ## B2 — Checkpoint on significance, not on time | ||
| Call `save_session` with `trigger: "auto"` when ANY of these happens: | ||
| - a task or subtask completes; | ||
| - a decision with rationale is made; | ||
| - the user says anything implying an ending: "thanks", "that's all", "see you", "gtg", switching topics; | ||
| - roughly 30+ minutes of substantive work have passed since the last checkpoint; | ||
| - the user mentions switching tools, models, or machines. | ||
| Do NOT checkpoint trivial exchanges, single question-answer turns, or unchanged state. Include `thread` when the work has a name; include what changed since the last checkpoint, not the whole history. | ||
| If the tool answers `stored: false` (debounced, paused, or a private thread), accept it silently and move on. Never retry an automatic checkpoint, and never argue with a pause. | ||
| ## B3 — Handoff detection | ||
| If the user implies someone or something else will continue ("hand this off", "my teammate will pick this up", "I'll continue on my phone"), produce a FULL handoff digest with `handoff: true` and all six sections: state (done / in progress / not started), key_decisions with the rationale, ordered open_items with blockers named, gotchas, artifacts (each with a one-line role), and suggested_first_prompt for whoever resumes. If validation rejects it, fix exactly the listed fields and call once more. | ||
| ## B4 — Visibility (non-negotiable) | ||
| Every automatic save must be announced in the conversation in one short line: | ||
| ✓ Checkpointed to ctxfile (thread: Q3 campaign) | ||
| Never save silently. If you saved without a thread, say so: "✓ Checkpointed to ctxfile". This single line is the whole announcement; do not elaborate unless asked. | ||
| ## B5 — Thread hygiene | ||
| A new project or a clearly distinct workstream gets a new thread name; do not append unrelated work to an existing thread. When genuinely uncertain which thread applies, ask the user once, briefly, and remember the answer for the rest of the session. | ||
| ## B6 — The CLI (harnesses with a shell) | ||
| If you can run shell commands, the `ctxfile` CLI is available for the admin actions the MCP tools deliberately do not expose. Run these ONLY when the user explicitly asks, never on your own initiative, and state the command you ran: | ||
| - "stop auto-saving" / "pause ctxfile" → `ctxfile pause` (resume with `ctxfile resume`) | ||
| - "make this thread private" → `ctxfile threads` to find the id, then `ctxfile threads private <id>` (`--off` reverses it) | ||
| - "what has been captured?" → `ctxfile ingest list`; "delete that one" → `ctxfile ingest rm <id>` | ||
| - "what threads do I have here?" → `ctxfile threads` | ||
| - "export context for the repo / CI" → `ctxfile export` | ||
| - "sync now" → `ctxfile sync` (works only if the user's vault passphrase env var is already set; if the command reports it is missing, tell the user to run it themselves — NEVER ask for, echo, or handle the passphrase) | ||
| Never run `ctxfile vault create|join` or `ctxfile activate` yourself; those are the user's own setup steps. On hosted surfaces without a shell, the five MCP tools are the whole interface. | ||
| ## Manual override | ||
| All of this coexists with explicit requests: "save this session", "pick up my X thread", and "hand this off" always work and take priority. Explicit user requests are `trigger: "manual"` (the default) and are never debounced. |
| --- | ||
| name: ctxfile | ||
| description: Automatic context checkpointing via the ctxfile MCP tools. Use throughout every session - at session start (load context), when tasks complete or decisions are made (checkpoint), and when the user hands work off or says goodbye. | ||
| --- | ||
| # ctxfile behaviors (v1) | ||
| You have access to the ctxfile MCP tools (`get_context`, `save_session`, `continue_thread`, `list_threads`, `ingest_context`). These behaviors make context capture automatic. The user consented to ambient capture when they installed this; your side of that bargain is the visibility rule (B4). | ||
| ## B1 — Session start | ||
| At the start of work, call `get_context`. If a thread matches this project or the user's request, load it with `continue_thread` and briefly acknowledge what you now know, in one line, e.g. "Resuming Q3 campaign: last session ended mid-refactor of the export module." Do not recite the whole digest back. | ||
| ## B2 — Checkpoint on significance, not on time | ||
| Call `save_session` with `trigger: "auto"` when ANY of these happens: | ||
| - a task or subtask completes; | ||
| - a decision with rationale is made; | ||
| - the user says anything implying an ending: "thanks", "that's all", "see you", "gtg", switching topics; | ||
| - roughly 30+ minutes of substantive work have passed since the last checkpoint; | ||
| - the user mentions switching tools, models, or machines. | ||
| Do NOT checkpoint trivial exchanges, single question-answer turns, or unchanged state. Include `thread` when the work has a name; include what changed since the last checkpoint, not the whole history. | ||
| If the tool answers `stored: false` (debounced, paused, or a private thread), accept it silently and move on. Never retry an automatic checkpoint, and never argue with a pause. | ||
| ## B3 — Handoff detection | ||
| If the user implies someone or something else will continue ("hand this off", "my teammate will pick this up", "I'll continue on my phone"), produce a FULL handoff digest with `handoff: true` and all six sections: state (done / in progress / not started), key_decisions with the rationale, ordered open_items with blockers named, gotchas, artifacts (each with a one-line role), and suggested_first_prompt for whoever resumes. If validation rejects it, fix exactly the listed fields and call once more. | ||
| ## B4 — Visibility (non-negotiable) | ||
| Every automatic save must be announced in the conversation in one short line: | ||
| ✓ Checkpointed to ctxfile (thread: Q3 campaign) | ||
| Never save silently. If you saved without a thread, say so: "✓ Checkpointed to ctxfile". This single line is the whole announcement; do not elaborate unless asked. | ||
| ## B5 — Thread hygiene | ||
| A new project or a clearly distinct workstream gets a new thread name; do not append unrelated work to an existing thread. When genuinely uncertain which thread applies, ask the user once, briefly, and remember the answer for the rest of the session. | ||
| ## B6 — The CLI (harnesses with a shell) | ||
| If you can run shell commands, the `ctxfile` CLI is available for the admin actions the MCP tools deliberately do not expose. Run these ONLY when the user explicitly asks, never on your own initiative, and state the command you ran: | ||
| - "stop auto-saving" / "pause ctxfile" → `ctxfile pause` (resume with `ctxfile resume`) | ||
| - "make this thread private" → `ctxfile threads` to find the id, then `ctxfile threads private <id>` (`--off` reverses it) | ||
| - "what has been captured?" → `ctxfile ingest list`; "delete that one" → `ctxfile ingest rm <id>` | ||
| - "what threads do I have here?" → `ctxfile threads` | ||
| - "export context for the repo / CI" → `ctxfile export` | ||
| - "sync now" → `ctxfile sync` (works only if the user's vault passphrase env var is already set; if the command reports it is missing, tell the user to run it themselves — NEVER ask for, echo, or handle the passphrase) | ||
| Never run `ctxfile vault create|join` or `ctxfile activate` yourself; those are the user's own setup steps. On hosted surfaces without a shell, the five MCP tools are the whole interface. | ||
| ## Manual override | ||
| All of this coexists with explicit requests: "save this session", "pick up my X thread", and "hand this off" always work and take priority. Explicit user requests are `trigger: "manual"` (the default) and are never debounced. |
| --- | ||
| name: ctxfile | ||
| description: Automatic context checkpointing via the ctxfile MCP tools. Use throughout every session - at session start (load context), when tasks complete or decisions are made (checkpoint), and when the user hands work off or says goodbye. | ||
| --- | ||
| # ctxfile behaviors (v1) | ||
| You have access to the ctxfile MCP tools (`get_context`, `save_session`, `continue_thread`, `list_threads`, `ingest_context`). These behaviors make context capture automatic. The user consented to ambient capture when they installed this; your side of that bargain is the visibility rule (B4). | ||
| ## B1 — Session start | ||
| At the start of work, call `get_context`. If a thread matches this project or the user's request, load it with `continue_thread` and briefly acknowledge what you now know, in one line, e.g. "Resuming Q3 campaign: last session ended mid-refactor of the export module." Do not recite the whole digest back. | ||
| ## B2 — Checkpoint on significance, not on time | ||
| Call `save_session` with `trigger: "auto"` when ANY of these happens: | ||
| - a task or subtask completes; | ||
| - a decision with rationale is made; | ||
| - the user says anything implying an ending: "thanks", "that's all", "see you", "gtg", switching topics; | ||
| - roughly 30+ minutes of substantive work have passed since the last checkpoint; | ||
| - the user mentions switching tools, models, or machines. | ||
| Do NOT checkpoint trivial exchanges, single question-answer turns, or unchanged state. Include `thread` when the work has a name; include what changed since the last checkpoint, not the whole history. | ||
| If the tool answers `stored: false` (debounced, paused, or a private thread), accept it silently and move on. Never retry an automatic checkpoint, and never argue with a pause. | ||
| ## B3 — Handoff detection | ||
| If the user implies someone or something else will continue ("hand this off", "my teammate will pick this up", "I'll continue on my phone"), produce a FULL handoff digest with `handoff: true` and all six sections: state (done / in progress / not started), key_decisions with the rationale, ordered open_items with blockers named, gotchas, artifacts (each with a one-line role), and suggested_first_prompt for whoever resumes. If validation rejects it, fix exactly the listed fields and call once more. | ||
| ## B4 — Visibility (non-negotiable) | ||
| Every automatic save must be announced in the conversation in one short line: | ||
| ✓ Checkpointed to ctxfile (thread: Q3 campaign) | ||
| Never save silently. If you saved without a thread, say so: "✓ Checkpointed to ctxfile". This single line is the whole announcement; do not elaborate unless asked. | ||
| ## B5 — Thread hygiene | ||
| A new project or a clearly distinct workstream gets a new thread name; do not append unrelated work to an existing thread. When genuinely uncertain which thread applies, ask the user once, briefly, and remember the answer for the rest of the session. | ||
| ## B6 — The CLI (harnesses with a shell) | ||
| If you can run shell commands, the `ctxfile` CLI is available for the admin actions the MCP tools deliberately do not expose. Run these ONLY when the user explicitly asks, never on your own initiative, and state the command you ran: | ||
| - "stop auto-saving" / "pause ctxfile" → `ctxfile pause` (resume with `ctxfile resume`) | ||
| - "make this thread private" → `ctxfile threads` to find the id, then `ctxfile threads private <id>` (`--off` reverses it) | ||
| - "what has been captured?" → `ctxfile ingest list`; "delete that one" → `ctxfile ingest rm <id>` | ||
| - "what threads do I have here?" → `ctxfile threads` | ||
| - "export context for the repo / CI" → `ctxfile export` | ||
| - "sync now" → `ctxfile sync` (works only if the user's vault passphrase env var is already set; if the command reports it is missing, tell the user to run it themselves — NEVER ask for, echo, or handle the passphrase) | ||
| Never run `ctxfile vault create|join` or `ctxfile activate` yourself; those are the user's own setup steps. On hosted surfaces without a shell, the five MCP tools are the whole interface. | ||
| ## Manual override | ||
| All of this coexists with explicit requests: "save this session", "pick up my X thread", and "hand this off" always work and take priority. Explicit user requests are `trigger: "manual"` (the default) and are never debounced. |
+3
-3
@@ -145,3 +145,3 @@ import { z } from 'zod'; | ||
| interface ConsultProviderSpec { | ||
| type: "anthropic" | "openai-compatible" | "ollama"; | ||
| type: "anthropic" | "openai-compatible" | "openrouter" | "ollama"; | ||
| model?: string; | ||
@@ -608,3 +608,3 @@ baseUrl?: string; | ||
| */ | ||
| declare const BEHAVIOR_HARNESSES: readonly ["claude-code", "cursor", "agents-md", "codex", "generic"]; | ||
| declare const BEHAVIOR_HARNESSES: readonly ["claude-code", "cursor", "opencode", "gemini", "agents-md", "codex", "openclaw", "hermes", "generic"]; | ||
| type BehaviorHarness = (typeof BEHAVIOR_HARNESSES)[number]; | ||
@@ -961,4 +961,4 @@ /** The canonical spec ships inside the npm package beside dist/. */ | ||
| declare const VERSION = "0.3.0"; | ||
| declare const VERSION = "0.3.1"; | ||
| export { BEHAVIOR_HARNESSES, type BehaviorHarness, type BehaviorState, type BuildEvent, type BuildExportOptions, type Connector, type ConnectorStatus, type ConsultProviderSpec, type ContextMeta, type ContextObject, type ContextScope, type CreateVaultOptions, DEFAULT_VAULT_CONFIG_PATH, EXPORT_PROFILES, EXPORT_SCHEMA_VERSION, EXPORT_SECTIONS, type ExportEnvelope, type ExportProfile, type ExportSection, type ExportedContext, type ExportedKeyFile, type FetchLike, type GitCommit, type GitState, HttpRelayStore, type HttpRelayStoreOptions, INGEST_SCHEMA_VERSION, type IngestArtifact, type IngestDoor, type IngestInput, type IngestResult, IngestStore, type IngestedSession, type JoinVaultOptions, type KdfParams, type KeyFile, type LoadConfigOptions, type LocalBlobSource, MASTER_KEY_BYTES, MIN_PASSPHRASE_LENGTH, type NotionConnectorOptions, type NotionPage, type OllamaSummarizerOptions, type ProLicenseInfo, type ProMemoryEntry, type ProModule, type ProUiApi, type ProUiFeatures, type RecoverVaultOptions, type RelayStore, type RenderedBehavior, type ResolvedConfig, type SaveSessionInput, type ServeTokenSpec, type ServerOptions, type SessionDigest, type SessionSyncPayload, SnapshotCache, type SnapshotInput, type SnapshotService, type Summarizer, type SyncBlobMeta, SyncClient, type SyncEntry, type SyncPayload, type SyncResult, type ThreadResolution, type ThreadSummary, type ThreadSyncPayload, TokenBudget, type UninstallResult, VERSION, type VaultConfig, type VaultMeta, type VaultView, assertPassphraseStrength, autoCaptureBlocked, buildContext, buildExportEnvelope, buildVaultView, clearBehaviorState, createNotionConnector, createOllamaSummarizer, createServer, createSnapshotService, createVault, decryptBlob, deriveBlobId, deriveMasterKey, detectHarnesses, encryptBlob, estimateTokens, fetchVaultMeta, fileConnector, filterScope, formatIngestErrors, fromBase64, generateRecoveryCode, generateSalt, gitConnector, inferHarnessFromClientName, ingestInputSchema, ingestSessionId, ingestSessionSchema, ingestSourceSchema, ingestToSessionDigest, inspectLicenseKey, installBehavior, isDeniedPath, joinVault, loadCanonicalBehaviors, loadConfig, loadProModule, loadVaultConfig, mergeIngestedSessions, normalizeRecoveryCode, openVaultSync, parseSyncPayload, readBehaviorState, recoverVault, redactContent, renderAllBehaviors, renderBehavior, renderExportMarkdown, renderThreadResume, resolveThread, saveSessionSchema, saveVaultConfig, scoreThreadMatch, sessionPayloadToIngestedSession, toBase64, truncateToTokens, uninstallBehavior, unlockVault, unwrapMasterKey, wrapMasterKey, writeBehaviorState, zeroKey }; |
+3
-3
@@ -145,3 +145,3 @@ import { z } from 'zod'; | ||
| interface ConsultProviderSpec { | ||
| type: "anthropic" | "openai-compatible" | "ollama"; | ||
| type: "anthropic" | "openai-compatible" | "openrouter" | "ollama"; | ||
| model?: string; | ||
@@ -608,3 +608,3 @@ baseUrl?: string; | ||
| */ | ||
| declare const BEHAVIOR_HARNESSES: readonly ["claude-code", "cursor", "agents-md", "codex", "generic"]; | ||
| declare const BEHAVIOR_HARNESSES: readonly ["claude-code", "cursor", "opencode", "gemini", "agents-md", "codex", "openclaw", "hermes", "generic"]; | ||
| type BehaviorHarness = (typeof BEHAVIOR_HARNESSES)[number]; | ||
@@ -961,4 +961,4 @@ /** The canonical spec ships inside the npm package beside dist/. */ | ||
| declare const VERSION = "0.3.0"; | ||
| declare const VERSION = "0.3.1"; | ||
| export { BEHAVIOR_HARNESSES, type BehaviorHarness, type BehaviorState, type BuildEvent, type BuildExportOptions, type Connector, type ConnectorStatus, type ConsultProviderSpec, type ContextMeta, type ContextObject, type ContextScope, type CreateVaultOptions, DEFAULT_VAULT_CONFIG_PATH, EXPORT_PROFILES, EXPORT_SCHEMA_VERSION, EXPORT_SECTIONS, type ExportEnvelope, type ExportProfile, type ExportSection, type ExportedContext, type ExportedKeyFile, type FetchLike, type GitCommit, type GitState, HttpRelayStore, type HttpRelayStoreOptions, INGEST_SCHEMA_VERSION, type IngestArtifact, type IngestDoor, type IngestInput, type IngestResult, IngestStore, type IngestedSession, type JoinVaultOptions, type KdfParams, type KeyFile, type LoadConfigOptions, type LocalBlobSource, MASTER_KEY_BYTES, MIN_PASSPHRASE_LENGTH, type NotionConnectorOptions, type NotionPage, type OllamaSummarizerOptions, type ProLicenseInfo, type ProMemoryEntry, type ProModule, type ProUiApi, type ProUiFeatures, type RecoverVaultOptions, type RelayStore, type RenderedBehavior, type ResolvedConfig, type SaveSessionInput, type ServeTokenSpec, type ServerOptions, type SessionDigest, type SessionSyncPayload, SnapshotCache, type SnapshotInput, type SnapshotService, type Summarizer, type SyncBlobMeta, SyncClient, type SyncEntry, type SyncPayload, type SyncResult, type ThreadResolution, type ThreadSummary, type ThreadSyncPayload, TokenBudget, type UninstallResult, VERSION, type VaultConfig, type VaultMeta, type VaultView, assertPassphraseStrength, autoCaptureBlocked, buildContext, buildExportEnvelope, buildVaultView, clearBehaviorState, createNotionConnector, createOllamaSummarizer, createServer, createSnapshotService, createVault, decryptBlob, deriveBlobId, deriveMasterKey, detectHarnesses, encryptBlob, estimateTokens, fetchVaultMeta, fileConnector, filterScope, formatIngestErrors, fromBase64, generateRecoveryCode, generateSalt, gitConnector, inferHarnessFromClientName, ingestInputSchema, ingestSessionId, ingestSessionSchema, ingestSourceSchema, ingestToSessionDigest, inspectLicenseKey, installBehavior, isDeniedPath, joinVault, loadCanonicalBehaviors, loadConfig, loadProModule, loadVaultConfig, mergeIngestedSessions, normalizeRecoveryCode, openVaultSync, parseSyncPayload, readBehaviorState, recoverVault, redactContent, renderAllBehaviors, renderBehavior, renderExportMarkdown, renderThreadResume, resolveThread, saveSessionSchema, saveVaultConfig, scoreThreadMatch, sessionPayloadToIngestedSession, toBase64, truncateToTokens, uninstallBehavior, unlockVault, unwrapMasterKey, wrapMasterKey, writeBehaviorState, zeroKey }; |
+20
-6
| { | ||
| "manifest_version": "0.2", | ||
| "manifest_version": "0.3", | ||
| "name": "ctxfile", | ||
| "display_name": "ctxfile", | ||
| "version": "0.1.0", | ||
| "version": "0.3.1", | ||
| "description": "Local-first MCP server that snapshots your project's working state (files, git, Notion, local-LLM summary) into a structured context object.", | ||
| "long_description": "ctxfile assembles a structured snapshot of a project — plan documents, key files (gitignore-aware, secret-redacted, token-budgeted), git state, and optionally Notion pages and a local Ollama summary — and serves it over stdio as MCP resources (context://current, context://plan, context://git), a get_context tool, and a load-context prompt. Nothing leaves your machine by default.", | ||
| "long_description": "ctxfile assembles a structured snapshot of a project \u2014 plan documents, key files (gitignore-aware, secret-redacted, token-budgeted), git state, and optionally Notion pages and a local Ollama summary \u2014 and serves it over stdio as MCP resources (context://current, context://plan, context://git), a get_context tool, and a load-context prompt. Nothing leaves your machine by default.", | ||
| "author": { | ||
@@ -12,3 +12,9 @@ "name": "ctxfile" | ||
| "license": "Apache-2.0", | ||
| "keywords": ["context", "local-first", "git", "notion", "ollama"], | ||
| "keywords": [ | ||
| "context", | ||
| "local-first", | ||
| "git", | ||
| "notion", | ||
| "ollama" | ||
| ], | ||
| "server": { | ||
@@ -19,3 +25,7 @@ "type": "node", | ||
| "command": "node", | ||
| "args": ["${__dirname}/dist/cli.js", "--root", "${user_config.project_root}"], | ||
| "args": [ | ||
| "${__dirname}/dist/cli.js", | ||
| "--root", | ||
| "${user_config.project_root}" | ||
| ], | ||
| "env": {} | ||
@@ -33,3 +43,7 @@ } | ||
| "compatibility": { | ||
| "platforms": ["darwin", "linux", "win32"], | ||
| "platforms": [ | ||
| "darwin", | ||
| "linux", | ||
| "win32" | ||
| ], | ||
| "runtimes": { | ||
@@ -36,0 +50,0 @@ "node": ">=20" |
+1
-1
| { | ||
| "name": "ctxfile", | ||
| "version": "0.3.0", | ||
| "version": "0.3.1", | ||
| "description": "Local-first MCP server that snapshots your project's working state (files, git, Notion, local-LLM summary) into a structured context object for any MCP client.", | ||
@@ -5,0 +5,0 @@ "mcpName": "dev.ctxfile/ctxfile", |
+1
-1
@@ -62,3 +62,3 @@ # ctxfile | ||
| With an active [Pro](https://ctxfile.dev/pricing) license the server also registers `remember` / `recall` / `forget` (AES-256-GCM encrypted cross-session memory, key in the OS keychain), `consult` (ask several providers the same question over live context), and `transcribe_voice` (local whisper.cpp) — each gated on its licensed feature, and the snapshot gains `sessions`: redacted digests of your recent sessions from **Claude Code, Cursor, Codex CLI, OpenCode, Gemini CLI, Aider, OpenClaw, and Hermes Agent**, so an agent in one tool picks up where an agent in another left off. Licensing is an Ed25519-signed key verified offline (`ctxfile activate <key>`); no phone-home, ever. | ||
| With an active [Pro](https://ctxfile.dev/pricing) license the server also registers `remember` / `recall` / `forget` (AES-256-GCM encrypted cross-session memory, key in the OS keychain), `consult` (ask several providers the same question over live context: Anthropic, OpenRouter, any OpenAI-compatible endpoint, or local Ollama), `distill_playbook` / `list_playbooks` / `get_playbook` / `rm_playbook` (reusable prompts an AI distills from your own saved sessions, stored encrypted), and `transcribe_voice` (local whisper.cpp) — each gated on its licensed feature, and the snapshot gains `sessions`: redacted digests of your recent sessions from **Claude Code, Cursor, Codex CLI, OpenCode, Gemini CLI, Aider, OpenClaw, and Hermes Agent**, so an agent in one tool picks up where an agent in another left off. Licensing is an Ed25519-signed key verified offline (`ctxfile activate <key>`); no phone-home, ever. | ||
@@ -65,0 +65,0 @@ On any *other* harness (or when a parser breaks), the free fallback is `ingest_context`: paste a short prompt, the agent digests its own session and pushes it in — strict schema, redacted, provenance-stamped `reported_by: agent`, reviewable via `ctxfile ingest list` / `rm <id>`. Parsers win on conflicts. The prompt is the adapter, so every MCP-speaking harness is supported, including ones that don't exist yet. |
Sorry, the diff of this file is too big to display
Sorry, the diff of this file is too big to display
Sorry, the diff of this file is too big to display
Sorry, the diff of this file is too big to display
Sorry, the diff of this file is too big to display
Sorry, the diff of this file is too big to display
New alerts
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
Fixed alerts
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
Improved metrics
- Total package byte prevSize
1787136
2.17%- Number of package files
31
14.81%- Lines of code
12571
1.43%No dependency changes