mirror of
https://github.com/mksglu/context-mode.git
synced 2026-09-19 03:27:16 +08:00
main
9 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
1aee4808d0 | fix(install): derive version from package.json across all manifests so none bake stale (#768) | ||
|
|
9f34c6f11b |
Add GitHub Copilot CLI + Antigravity CLI (agy) support (#787)
* feat(adapters): add Antigravity CLI (agy) + GitHub Copilot CLI support
Add two agentic CLI adapters onto next's existing adapter registration —
without the abandoned PR's setup subcommand / consolidated registry.
Antigravity CLI (agy):
- MCP + capture-only PostToolUse hook adapter (agy honors no stdout veto in
auto-run mode; verified against agy 1.0.5). The agy hook payload
{conversationId, toolCall, workspacePaths} is mapped onto the shared
capture pipeline.
- Ships a Claude-layout plugin bundle (configs/antigravity-cli/) installed via
`npm run install:agy` (mirrors install:openclaw), with a version-skew
capture-hook probe in the installer.
GitHub Copilot CLI (1.0.59):
- json-stdio hook adapter with six events: PreToolUse, PostToolUse, PreCompact,
SessionStart, UserPromptSubmit, Stop. Overrides CopilotBaseAdapter to emit the
FLAT {type,command} + top-level "version": 1 hook config Copilot CLI requires.
- MCP install via `copilot mcp add context-mode -- context-mode`.
- Fix a latent Stop-hook bug: a session_end event with no `data` threw inside
insertEvent (createHash(undefined)) and was silently dropped.
Cross-cutting:
- #774: probe agy/copilot config markers before the generic ~/.claude check.
The copilot marker is narrowed to context-mode-written files
(~/.copilot/mcp-config.json | hooks/context-mode.json), not a bare ~/.copilot/
dir, so a co-installed-but-unconfigured Copilot CLI cannot steal detection
from a Claude Code user.
- Dispatcher fails OPEN (exit 0) on a missing hook script: GitHub Copilot CLI
treats an exit-1 PreToolUse hook as DENY, so a version skew (a newer adapter's
hook command on an older global) would otherwise brick the agent.
Fixes #774. Fixes #775.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* ci: regenerate bundles for antigravity-cli + copilot-cli support
Picks up the new HOOK_MAP entries, client-map keys, validPlatforms,
getSessionDirSegments cases, and the fail-open dispatcher into the
esbuild-generated runtime bundles.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* docs(platform-support): sync support docs to 18 platforms + fix stale Kiro classification
Make README.md and docs/platform-support.md internally consistent and aligned
with the adapter source of truth.
Header sync (18 platforms everywhere):
- The Main Comparison Table (was 11 cols), the Capability Matrix (was 11), and
the README Platform Compatibility table (was 17, missing Kimi Code) now list
the SAME 18 platforms in one shared order. Adds the two branch-new platforms
(GitHub Copilot CLI, Antigravity CLI `agy`) plus previously-omitted Qwen Code,
KiloCode, OpenClaw, Zed, Pi as columns. Each cell sourced from the per-platform
detail sections / adapter source and independently verified.
- Fix five ragged rows in the Main Comparison Table (a dropped trailing OMP cell)
and add CLI Hook Dispatcher rows for qwen-code + copilot-cli.
- GitHub Copilot CLI section: normalize the `**Hook Names:**` label and add the
missing `**Output Modification:**` field for json-stdio-family parity.
Fix stale Kiro classification (code is the source of truth):
- The kiro adapter is json-stdio with working preToolUse/postToolUse hooks
(hooks/kiro/{pretooluse,posttooluse}.mjs + a kiro HOOK_MAP entry), yet the docs
called it "MCP-only (Phase 2 — not implemented)" and the README contradicted
itself ("no hook support" in one place, "native preToolUse/postToolUse" in two
others).
- Reclassify Kiro as json-stdio with PreToolUse + PostToolUse + exit-code-2
blocking across the Overview paradigm table, both wide tables, the dispatcher
table, and the Kiro detail section; document that agentSpawn (SessionStart) and
stop are not yet wired, so session restore after compaction is unavailable.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix(antigravity-cli): drop vestigial .mcp.json dependency that broke fresh clones
The agy plugin-bundle test asserted configs/antigravity-cli/.mcp.json, but
.mcp.json is gitignored repo-wide and was never committed — so the test passed
on the dev machine (file present locally) yet failed on a fresh clone with
ENOENT. Committing the file is the wrong fix: the .gitignore comment documents
that shipping .mcp.json has silently broken fresh installs before (#253/#531).
- The bundle declares MCP the Claude way via .claude-plugin/plugin.json
mcpServers (committed — the mechanism agy reads on `agy plugin install`),
mirrored by the agy-native mcp_config.json (committed). Remove the vestigial
bundle .mcp.json and stop the test + docs from requiring it. Every file the
plugin test reads is now git-tracked, so a fresh clone passes.
- README: Kiro was still grouped under "Non-hook platforms" in the routing-
enforcement note. Kiro has native preToolUse/postToolUse hooks; it needs the
manual KIRO.md copy only because agentSpawn/SessionStart is not yet wired.
Reword to say so.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix(adapters): cross-platform agy installer + copilot-cli COPILOT_HOME parity
Windows fix (real): replace the bash-only agy plugin installer with a
cross-platform Node script so `npm run install:agy` runs natively on Windows
(PowerShell/cmd), not just Git Bash/WSL. agy runs on Windows, so its installer
must too — the old `node -e` wrapper hard-exited 1 on win32. openclaw stays
bash-only (it is genuinely POSIX-only). Removes
scripts/install-antigravity-cli-plugin.sh in favor of
scripts/install-antigravity-cli-plugin.mjs (same preflight + version-skew probe).
copilot-cli hardening (COPILOT_HOME edge case only — the default ~/.copilot
install was and remains correct):
- CopilotCliAdapter.getSessionDir() now roots at getConfigDir() (COPILOT_HOME-
aware), mirroring codex/kimi, so the TS server reads sessions from the same
place the hook runtime (COPILOT_OPTS configDirEnv: COPILOT_HOME) writes them.
Previously a relocated COPILOT_HOME split hook writes ($COPILOT_HOME/...) from
server reads (~/.copilot/...), making sessions appear empty.
- detect.ts copilot-cli marker honors COPILOT_HOME, not just ~/.copilot.
No change to the default (COPILOT_HOME-unset) behavior; a regression test pins
both the ~/.copilot default and the COPILOT_HOME-rooted path.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* ci: regenerate bundles for copilot-cli COPILOT_HOME parity
Picks up CopilotCliAdapter.getSessionDir() and the COPILOT_HOME-aware detect.ts
marker into the esbuild runtime bundles.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix(antigravity-cli): installer registers the MCP server (agy plugin install skips it)
`npm run install:agy` ran only `agy plugin install`, which — verified against
agy 1.0.5 — processes a bundle's skills + hooks but logs "mcpServers : skipped
(not found)" and registers NO MCP server. agy reads a plugin's MCP only from a
bundle `.mcp.json` (intentionally not shipped — gitignored repo-wide after
#253/#531) and has no `agy mcp add` command, so context-mode's MCP server was
never registered: users had to add it to ~/.gemini/config/mcp_config.json by hand
(reported on Windows; reproduced on Linux: `mcpServers : skipped (not found)`).
The installer now also writes context-mode into agy's GLOBAL MCP profile
~/.gemini/config/mcp_config.json (idempotent JSON merge, preserves other servers,
tolerates a malformed file) — the file agy actually loads and `context-mode
doctor` checks. Verified end-to-end on agy 1.0.5: `npm run install:agy` →
mcp_config.json gains context-mode → `agy -p "... ctx_execute ... 7 + 5"` → 12.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix(server): emit Gemini-safe tool schemas so agy/Gemini CLI expose ctx_* tools
Antigravity CLI (agy) and Gemini CLI use Gemini's function-calling API, which
rejects JSON Schema `const` and `additionalProperties`. When a tool's parameter
schema contains either, the host SILENTLY DROPS that tool from the model's
function list — so agy never sees the ctx_* tools and works around them by
hand-rolling the MCP protocol through its Bash tool (verified on Windows: agy
wrote scratch/call_ctx_stats.js + list_mcp_tools.js MCP clients instead of
calling the tools natively). That defeats the point of context-mode — bash
output floods the context window instead of staying in the sandbox.
context-mode builds schemas with Zod, which emits `const` (from coerce/preprocess
constructs) and `additionalProperties`, with no Gemini sanitization. Wrap the
SDK's tools/list handler to rewrite the EMITTED schema:
- `const: X` -> `enum: [X]` (an identical single-value constraint)
- drop `additionalProperties` (advisory-only; every ctx_* handler parses args
with Zod, which strips unknown keys server-side regardless)
Both transforms are behavior-preserving for every other client (Claude Code,
Copilot, Cursor): const and a one-value enum are equivalent, and no model sends
undeclared properties — only the wire schema changes, never validation or how a
tool is called. Best-effort: if the MCP SDK internals shift, the original handler
is left untouched (no regression). Verified on the real tools/list: all 11 ctx_*
tools now emit 0 `const` / 0 `additionalProperties`.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* ci: regenerate bundles for Gemini-safe tool schema sanitizer
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix(antigravity-cli): clear agy's stale MCP tool-schema cache on install
agy caches each MCP server's tool schemas under
~/.gemini/antigravity-cli/mcp/<server>/ and does NOT refresh them on reconnect
(verified on agy 1.0.6 against a live Windows install). A cache captured by a
context-mode older than the Gemini-safe-schema fix (
|
||
|
|
1e73a13d19 |
fix(codex): make plugin discoverable via .agents/plugins/marketplace.json (#525)
PR #525 (tedjy971) reported that context-mode never shows up in Codex CLI's `/plugin` listing despite shipping a `.codex-plugin/marketplace.json`. The reported claims were verified against the Codex Rust source in refs/platforms/codex and OpenAI's published docs — all three load-bearing assertions hold: 1. Codex reads `MARKETPLACE_MANIFEST_RELATIVE_PATHS` = `[.agents/plugins/marketplace.json, .claude-plugin/marketplace.json]` (codex-rs/core-plugins/src/marketplace.rs:21). `.codex-plugin/ marketplace.json` is NOT in this list — Codex never opens it. 2. The local-plugin source `path` must be `./<subdir>`, not `./`. Codex's `resolve_local_plugin_source_path` (marketplace.rs:502-518) does `path.strip_prefix("./")` then rejects empty results with `"local plugin source path must not be empty"`. Our shipped `.claude-plugin/marketplace.json` uses `source: "./"`, which hits this rejection. The error is swallowed silently at marketplace.rs: 446-452 via `warn!(... skipping marketplace plugin that failed to resolve)`, so `codex plugin marketplace add` succeeds with exit 0 but the plugins vec is empty and the user sees nothing in /plugin. 3. `${CODEX_PLUGIN_ROOT}` / `${CLAUDE_PLUGIN_ROOT}` placeholders are NOT interpolated by Codex (upstream openai/codex#19582 OPEN). Grep of codex-rs/core-plugins/src/ confirms zero `interpolat*` / `expand_env*` / `envsubst*` logic in non-test source code. These were also corroborated by OpenAI's own docs at https://developers.openai.com/codex/plugins/build which spell out: - "a repo marketplace at $REPO_ROOT/.agents/plugins/marketplace.json" - "source.path points to that plugin directory with a `./`-prefixed relative path" (example: `./plugins/my-plugin`) - "Only plugin.json belongs in .codex-plugin/" End-to-end verification with Codex CLI v0.130.0: $ codex plugin marketplace add /path/to/context-mode Added marketplace `context-mode`. No silent-drop warning emitted by the warn! path now that source.path resolves to a real plugin tree. Changes: 1. Add .agents/plugins/marketplace.json with canonical schema: { name, interface: { displayName }, plugins: [{ name, source: { source: "local", path: "./plugins/context-mode" }, policy, category }] } Matches the Rust serde shape at marketplace.rs:694-744 exactly. 2. Add plugins/context-mode symlink → repo root, so Codex's `resolve_local_plugin_source_path` lands on a directory that contains `.codex-plugin/plugin.json` (the per-plugin manifest path Codex's load_plugin_manifest expects). 3. Delete .codex-plugin/marketplace.json (dead — Codex never reads it, keeping it ships dead bytes and misleads contributors). 4. Remove .codex-plugin/marketplace.json from version-sync.mjs targets and from the `version` lifecycle git-add list. The Codex marketplace schema has no top-level `version` field per the Rust serde struct, so the new .agents/plugins/marketplace.json doesn't need syncing. Per-plugin version still flows through .codex-plugin/plugin.json which remains in the targets list. 5. Add tests/codex/marketplace-layout.test.ts (6 tests) that mirror Codex's exact discovery logic — strip_prefix("./"), non-empty check, plugin.json presence, placeholder absence — so future drift produces a deterministic local failure long before users hit it. 6. Update tests/plugins/codex-manifest.test.ts and tests/scripts/ version-sync.test.ts to reflect the deletion (with comments pointing at the Rust line numbers for future maintainers). Why we shipped our own fix instead of merging tedjy971's PR #525: Same end-state, more rigor — full Rust-source citations, mirror-the- deserializer tests, e2e verification with the v0.130.0 CLI. Their analysis pointed us at the right problem; this commit gives the project a durable test contract so a regression can't slip past CI silently like the original bug did. Credit: tedjy971's PR #525 surfaced the issue and the canonical layout. |
||
|
|
308a80f9a3 |
fix(codex): add .codex-plugin/* to version-sync targets (extends PR #512 by @tedjy971)
Without this, every release bump would drift `.codex-plugin/plugin.json` and `.codex-plugin/marketplace.json` further out of sync with the canonical `package.json:version`. Same hazard previously hit `.cursor-plugin/plugin.json` (stuck at v1.0.111 vs current v1.0.118) because it was missing from BOTH the targets[] in version-sync.mjs and the npm `version` lifecycle `git add` list. Two-part fix: - `scripts/version-sync.mjs` → append the two Codex manifests to `targets[]` (so the rewrite touches them). - `package.json` → extend the `version` script's `git add` list to include the two Codex manifests AND `.cursor-plugin/plugin.json` (the cursor manifest had the same defect; without it staged, the rewrite is silently discarded by the npm `version` commit). End-to-end test in tests/scripts/version-sync.test.ts copies all manifests into a scratch repo with a synthetic version, runs the script, and asserts every (version | metadata.version | plugins[].version) field gets rewritten — catches future targets[] drift automatically. |
||
|
|
b465acd834 |
docs(omp): drop hardcoded version from install guide + prune redundant manifest field
The previous manual install path pasted a literal `"version": "1.0.111"`
into a JSON snippet for omp-plugins.lock.json. That number drifts
silently on every release — anyone reading the README a week from
now would copy a stale version into their lock file.
Verified upstream that the snippet was unnecessary in the first
place. The plugin loader at refs/platforms/oh-my-pi/packages/
coding-agent/src/extensibility/plugins/loader.ts:89-94 only consults
the lock file when a plugin is explicitly disabled:
const runtimeState = runtimeConfig.plugins[name];
if (runtimeState && !runtimeState.enabled) continue;
Plugins missing from the lock file load with default-enabled state.
So the manual install collapses to two commands: `cd ~/.omp/plugins`
+ `bun add context-mode`, then restart. No JSON to edit, no version
to pin.
Same logic eliminates the `omp.version` field we had been carrying in
the root package.json. The upstream loader stamps
`manifest.version = pluginPkg.version` from the top-level
package.json:version on every load (loader.ts:87), so duplicating it
inside the omp block adds a drift surface and zero signal. The
matching `pi` block follows the same convention, so consistent.
Drops the corresponding omp.version sync code from
scripts/version-sync.mjs — it can no longer drift if the field
doesn't exist.
|
||
|
|
2ddae394c4 |
feat(omp): plugin path with native hook enforcement (HookAPI tool_call/tool_result/session_start/session_before_compact)
Promotes OMP from MCP-only delivery to a proper plugin. `omp plugin
install context-mode` now wires programmatic enforcement equivalent to
Claude Code's PreToolUse/PostToolUse/PreCompact/SessionStart pipeline.
Verified end-to-end against the upstream OMP source cloned to
refs/platforms/oh-my-pi @ v3.20.1 (no LLM trust, every claim
file:line cited):
- Manifest format: `omp` or `pi` field on root package.json
Source: refs/.../extensibility/plugins/loader.ts:75
`const manifest = pluginPkg.omp || pluginPkg.pi;`
+ line 82: `manifest.version = pluginPkg.version;` (loader stamps
version from top-level pkg.version on load — explicit
`omp.version` is belt-and-suspenders, kept synced by
scripts/version-sync.mjs).
- Install command: `omp plugin install <pkg>` runs
`bun install <pkg>` inside ~/.omp/plugins per
refs/.../extensibility/plugins/manager.ts:158, then reads
`~/.omp/plugins/node_modules/<pkg>/package.json` for the manifest.
- HookFactory contract: `(pi: HookAPI) => void` per
refs/.../extensibility/hooks/types.ts:809.
- Block return shape: `{ block?: boolean; reason?: string }` per
refs/.../extensibility/hooks/types.ts:566.
- Event payloads:
- ToolCallEvent (refs/.../hooks/types.ts:448): {toolName, toolCallId, input}
- ToolResultEvent (refs/.../hooks/types.ts:461 onward): {toolName, toolCallId, input, content[], isError}
- Example reference: refs/.../examples/hooks/permission-gate.ts.
What the plugin actually does:
- tool_call: hard-blocks bash containing curl/wget/inline-fetch
(`requests.get`, `http.get`, `Invoke-WebRequest`, etc.) — same
pattern set as the Pi extension.
- tool_result: feeds OMP-shaped events through the existing
extractEvents pipeline → SessionDB at ~/.omp/context-mode/.
- session_start: derives a stable 16-hex session id from
sessionManager.getSessionFile() (or wall-clock fallback), runs
7-day cleanup.
- session_before_compact: persists a buildResumeSnapshot output via
upsertResume + increments compact_count for resume-on-restart.
Reference parity:
- Mirrors src/adapters/pi/extension.ts shape closely. OMP differs in
two ways that justify a dedicated file:
1. Storage at ~/.omp/context-mode/ via OMPAdapter (not ~/.pi/)
2. OMP has native MCP via mcp.json — the Pi extension's
mcp-bridge.ts is dead weight under OMP and is intentionally
omitted here.
- Mirrors src/adapters/openclaw/plugin.ts integration shape (root
package.json field → built JS entry).
Smoke test (run locally before commit):
- pkg.omp.hooks resolves to build/adapters/omp/plugin.js ✓
- default export is a function ✓
- 4 handlers register: session_start, tool_call, tool_result,
session_before_compact ✓
- tool_call({toolName: 'bash', input: {command: 'curl ...'}}) →
{block: true, reason: '...'} ✓
Tests: tests/adapters/omp-plugin.test.ts adds 17 cases across 4 TDD
slices (routing, extraction, session lifecycle, resume snapshot). All
green. Full vitest run: 2642 passed, 20 skipped, 0 failed.
scripts/version-sync.mjs now also stamps package.json:omp.version
when running on `npm version` lifecycle so OMP manifest version
never drifts from top-level pkg.version (verified by simulating a
stale 0.0.0 value and watching it correct to current).
README updated:
- OMP install section reordered: plugin path is now primary, with
upstream file:line citations for the loader and block contract;
MCP-only path retained as the alternative.
- Hook coverage table (lines ~1024-1031): OMP rows promoted from
"--" to ✓ (via tool_call event), etc.
- Platform compatibility table: OMP PreToolUse/PostToolUse/
SessionStart/PreCompact/CanBlockTools all marked Plugin.
- Routing-enforcement note: OMP moved from non-hook list to
hook-capable list.
- All "OMP MCP-only / no hook integration" prose paragraphs
rewritten.
|
||
|
|
7b86ee5a20 |
feat(cursor): add Marketplace plugin packaging (#489)
* feat(cursor): add Marketplace plugin packaging
Mirror the Claude Code plugin layout for Cursor's plugin marketplace:
- .cursor-plugin/plugin.json: manifest pointing at ./configs/cursor/context-mode.mdc, ./skills/, ./hooks/cursor/hooks.json, and an MCP server entry running 'npx -y context-mode'.
- hooks/cursor/hooks.json: registers preToolUse, postToolUse, sessionStart, afterAgentResponse, and stop, all dispatched through 'npx -y context-mode hook cursor <event>' so users do not need a local clone.
- src/adapters/cursor/index.ts: doctor now detects plugin installs under ~/.cursor/plugins/{local,cache} and warns when both the plugin and a native .cursor/hooks.json register context-mode hooks.
- scripts/version-sync.mjs: keeps .cursor-plugin/plugin.json in lockstep with package.json.
- README.md, docs/platform-support.md: document the Marketplace install path alongside the existing manual install.
Refs #485
* feat(cursor): add plugin README + drop non-schema displayName field
- Add .cursor-plugin/README.md so the Marketplace tile has a dedicated landing page (project root README is unchanged).
- Remove 'displayName' from .cursor-plugin/plugin.json: the field is not in Cursor's plugin manifest schema (https://cursor.com/docs/reference/plugins) and would be flagged by the validator.
Validated all manifest keys against the official schema; no other extra fields. Cursor adapter test suite: 50/50 pass.
* feat(cursor): add Marketplace logo
Adds .cursor-plugin/assets/logo.png and references it via the manifest 'logo' field. Cursor resolves relative paths to raw.githubusercontent.com URLs at the commit SHA, so the Marketplace tile renders the snowflake icon directly from the repo.
* docs(cursor): add local-install quickstart for testers
Document the robocopy/symlink workflow so reviewers (and early adopters) can try the plugin from the repo before Marketplace acceptance. Calls out the Windows symlink limitation explicitly so testers do not waste time debugging mklink.
* docs(cursor): mark Marketplace plugin as work-in-progress until review
Per maintainer feedback: until Cursor's review team lists the plugin, the README needs an explicit 'work in progress' notice plus copy-pasteable local-install commands for both Windows (robocopy) and macOS/Linux (ln -s). Calls out the Windows symlink limitation directly so testers do not waste time debugging mklink.
Refs #485, #489
---------
Co-authored-by: Maxwell_sun <Maxwell_sun@noreply.gitcode.com>
Co-authored-by: Mert Köseoğlu <bm.ksglu@gmail.com>
|
||
|
|
7ac0c451ef |
fix: include Pi extension in version-sync targets
The .pi/extensions/context-mode/package.json had a hardcoded version that wasn't synced by the version lifecycle hook. Now included in both the sync script targets and git add staging. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> |
||
|
|
eb8717aa8a |
refactor: single source of truth for version (package.json)
- src/server.ts reads version from package.json via createRequire - scripts/version-sync.mjs syncs to all 5 JSON manifests - npm `version` lifecycle hook auto-runs sync + stages files - Fixed OpenClaw manifests: 1.0.20/1.0.21 → 1.0.23 - Bump to 1.0.23 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> |