wuisabel-gif/MemWhale

Capture Codex commands and give Codex proactive recall mw integrate codex only configures MCP today: MemoryWhale does not record Codex's shell commands (see integrations/codex/README.md, "Automatic execution capture: No"), so Codex gets neither command history nor the proactive-recall notes Claude Code and Cursor now receive (#376, #388). Codex has a PostToolUse hook (~/.codex/hooks.json) that can return hookSpecificOutput.additionalContext into the model's context, the same shape Claude Code uses: https://developers.openai.com/codex/hooks Scope A capture adapter: mw-remember --from-hook codex parses Codex's PostToolUse payload for shell tools (command, cwd, exit code, output) into a CommandRecord, like crates/mw-cli/src/agent_hook.rs does for Claude and Rho. Install and revert it from mw integrate codex --capture (see crates/mw-cli/src/integrate/cursor_capture.rs for the opt-in, check, and revert pattern). Return the existing note from feedback_note in crates/mw-cli/src/bin/mw-rememb

First contribution: try proactive recall in a real Cursor session MemoryWhale's Cursor capture hook now answers back: when a shell command fails with an error a later command fixed before, Cursor's agent receives one line naming that fix, and when a command passes right after failing, the agent is asked to save the lesson (#388). It is tested with payloads built from Cursor's hook documentation, but nobody has tried it in a live Cursor session yet. That is the whole task: try it and report what happens. No Rust or code needed. Start here Install MemoryWhale (see the README) and run mw integrate cursor --capture. In a throwaway project, have Cursor's agent run a command that fails with a clear error, then run the command that fixes it, then the original command again (for example a missing tool or file). Make the same error happen again in a new chat. Check whether the agent's context shows a line starting with MemoryWhale:, and whether the agent mentions or uses it. Report back Comme

One place to track new agent-client integrations that are still in the research or planning stage. Each sub-issue keeps its own pinned evidence and acceptance criteria. This issue tracks priority and status. Candidates Issue Client Status Notes #294 Mistral Vibe Recommended next stdio MCP and skills, so the smallest surface #295 Qwen Code Planned Verify actual semantics; don't copy the Gemini guide #297 OpenHands SDK Planned Different deployment boundary: container and remote runtimes Done: Kimi Code (#296, shipped in #298). Shared requirements Every integration follows integrations/TEMPLATE.md, stays in the Interfaces layer (docs/architecture.md), and reuses mw-mcp. Each one needs: a pinned client version real tool discovery through the native client an isolated synthetic store a safe uninstall path Want to help? If you use one of these clients every day, you're the ideal person to pick it up. Comment on its issue. New to the project? Start with #317.

Thanks for looking at MemoryWhale! This issue is the front door for new contributors. You don't need to know the whole codebase, and you don't need Rust for most of these. 1. Pick a task Comment on the issue you want so nobody duplicates work. Each one lists the files to touch and a command to check your change. No Rust needed #222: proofread a translation. Spanish and Brazilian Portuguese are new and have had no native review yet; Arabic, German, French, Japanese, Korean, and Simplified or Traditional Chinese need review too. Even one section helps. #392: try the new proactive-recall notes in a real Cursor session and report what the agent saw (no code) #266: add three rows to a Vitest table (TypeScript, one file) #130, #133, #129: fix outdated Linux, SOP, and Jetson setup docs (SOP and Jetson docs now live in docs/project/) #255: document live autosave and interrupted-session recovery Small Rust tasks #254: test mw --help output (the version flags are already covered) #253: test f

Find a safe capture path for Codewhale beyond the TUI Research how MemoryWhale could observe Codewhale headless execution without depending on interactive TUI hooks or introducing a second agent loop. Why it matters: a TUI integration does not automatically cover scripts, app-server/ACP, or workflow execution. We should establish the real execution boundary before promising support everywhere. Start here Use #281 and #282 as the plugin/TUI baseline, not as evidence of headless support. Inspect a pinned Codewhale version's CLI event streams, receipts, existing tool execution observers, and the shared Engine::run_turn consumers. The inspected checkout's hook contract excludes headless codewhale exec, app-server/ACP, and workflow/subagent internals from TUI-hook delivery. Questions to answer Surface Evidence to establish Headless exec Can an existing public result/event stream supply command, cwd, output, status, and stable IDs? App-server / ACP Which observed events are availa