fix(aidd-context): the memory hook wired into ~/.gemini/settings.json never runs under Antigravity, and fails silently

Start with the README tool-support table and plugins/aidd-context/hooks/update_memory.js, then run agy --output-format json -p "/hooks" and inspect the documented cli-*.log path. Verify the described hooks.json customization roots, SessionStart behavior, and cwd/workspacePaths details. Done means the Antigravity guidance records the correct declaration file and the future install path is not directed to settings.json.

Description

Wiring AIDD's memory hook (plugins/aidd-context/hooks/update_memory.js) into ~/.gemini/settings.json — the natural guess for a Gemini-family tool, since Antigravity keeps everything else under ~/.gemini/ — produces nothing at all under Antigravity (agy). The hook never loads, and nothing anywhere says so. A hook declared in a file the tool never reads is indistinguishable from a hook that ran and did nothing.

This is not a regression in shipped code: the framework writes no such file today, and there is no Gemini or Antigravity tool profile in the CLI — the README lists Gemini · Mistral as 🚧 In progress. It is the trap waiting for whoever wires it first, and for the Antigravity work coming out of #859. Cheaper to record now than to debug later, since the failure mode is total silence.

A correction to my own report in #859. There I described this declaration as using the Gemini-CLI hook vocabulary (BeforeAgent, AfterAgent, BeforeTool, AfterTool). That was wrong: on the machine I measured, those four entries belong to an unrelated third-party tool, not to AIDD. The AIDD entry is declared under SessionStart, which is a real agy event — present in the embedded proto, absent from the embedded guide (#859). The failure is therefore the file, not the event name, which makes it slightly worse than reported: a correct event name, in a file the hook manager never reads, with no diagnostic anywhere.

Affected file(s)

plugins/aidd-context/hooks/update_memory.js — the hook itself is correct; what is wrong is the location a person is led to declare it in. Downstream: the README tool-support table, and whichever Antigravity install path lands from #859.

Expected behaviour

One of, in increasing order of cost:

1. It is written down that agy reads hook declarations only from a file named hooks.json, in one of its customization roots — never from settings.json.
2. When Antigravity support lands (#859), the install path writes hooks.json rather than settings.json.

Observed behaviour

The hook never loads. agy 1.2.5, verified 2026-09-20 — same version as the #859 measurements of 2026-09-17, which is itself the point: this binary auto-updates.

The binary answers the question directly, in print mode, without starting a turn:

$ agy --output-format json -p "/hooks"
{"conversation_id":"","status":"SUCCESS","response":"vibe-island\tenabled\tPreInvocation …",
 "usage":{"input_tokens":0,"output_tokens":0,"total_tokens":0},
 "command":{"name":"hooks","data":{"hooks":[{"name":"vibe-island","enabled":true,
   "source":"/Users/<me>/.gemini/config/plugins/vibe-island/hooks.json", …}]}}}

One group, sourced from a hooks.json. The AIDD entry declared in ~/.gemini/settings.json does not appear.

The control is on the same machine, for free. That third-party tool is declared in both files — in ~/.gemini/settings.json under the Gemini-CLI event names, and in a plugin hooks.json under agy's own event names. Only the hooks.json declaration shows up in /hooks. Same tool, same run, same machine: the file is the only variable that moved.

Two corroborating facts, both from the binary itself:

• it logs what it loaded at every start, in ~/.gemini/antigravity-cli/log/cli-*.log:

  I0917 09:04:15.742883 1 hooks_manager.go:53] loaded 1 named hooks from 1 hooks.json file(s)
  

  a count that never includes anything declared in settings.json;
• its embedded help for customization roots says where hooks come from. Quoted as the binary actually holds them — a heading and list entries, not one sentence (strings, 1.2.5, 2026-09-20): "Customizations are automatically discovered and loaded from the following customization roots:", then "Within any of the customization roots above, you can define:", with "MCP Servers (mcp_config.json)" and "Hooks (hooks.json)" among the entries that follow.

Where it does work

• <project>/.agents/hooks.json — re-measured today, 2026-09-20, agy 1.2.5. In a throwaway git repository carrying only that file, agy --add-dir <repo> -p "/hooks" lists the probe beside the global plugin, each with the file it came from, for total_tokens: 0:

  issue890-project-probe  <-  <repo>/.agents/hooks.json
  vibe-island             <-  ~/.gemini/config/plugins/vibe-island/hooks.json
  

  Loaded is not fired, and the distinction is worth knowing. That /hooks run did not trigger SessionStart — no witness file. A real one-word prompt in the same repository did, and the probe recorded its own working directory:

  project  SessionStart  cwd=<repo>/.agents
  

  So the hook runs with its cwd one level below the repository root, not at the root. A hook that resolves the project from its own cwd — as update_memory.js does, to rewrite the open project's CLAUDE.md / AGENTS.md — has to account for that.

  Until the folder is trusted, this declaration is also silently inert — the same failure mode as the one this issue reports, which is why it needs documenting where a person meets it (#859). --add-dir <repo> opens the same door headless with no trust granted.

• ~/.gemini/config/hooks.json — the global customization root, also re-measured today, 2026-09-20, agy 1.2.5. A probe declared there alone, with the project declaration disabled, is listed by /hooks as coming straight from that file, with no plugin packaging:

  issue890-globalroot-probe  <-  ~/.gemini/config/hooks.json
  vibe-island                <-  ~/.gemini/config/plugins/vibe-island/hooks.json
  

  Launched from a working directory outside the repository, with --add-dir <repo>, it fires and records:

  global  SessionStart  cwd=~/.gemini/config
  

  and the payload it received carries no cwd at all — only the workspace:

  { "conversationId": "…", "transcriptPath": "…", "modelName": "…",
    "artifactDirectoryPath": "…", "workspacePaths": ["<repo>"] }
  

  So a hook installed at this target must resolve the project from workspacePaths[0]; its own cwd is ~/.gemini/config and names no repository. (That absence of cwd is also the premise of the handleFileWritten defect split out of #859 — the same measurement backs both.)

  The probe was removed afterwards; /hooks returning to vibe-island alone is the closing witness, and nothing remains in that root.

AI tool

Other — Antigravity (agy) 1.2.5.

aidd-cli version

5.3.0, built from source at next 83b0246e.

OS

macOS.

Additional context

Found during the #859 spike, kept out of that thread because it is not about telemetry, and split out here at the maintainer's request.

Two reusable facts worth having outside this issue, both used above:

• agy -p "/hooks" answers which hooks it loaded, and from which file, in print mode — total_tokens: 0 in the run quoted above, so it costs nothing to ask;
• ~/.gemini/antigravity-cli/log/cli-*.log carries the same answer as a count at every start.

Per #618, every Antigravity claim here carries its version and the date it was read: agy 1.2.5, 2026-09-17 and 2026-09-20. Nothing here should be taken as durable across versions of a binary that updated three times during a single spike.