Skip to content

Give Antigravity a NodeSpace plugin: hooks for project, skill list and refusal #3777

Closed

Description

@malibio

Problem

nodespace skill install gives Antigravity the skill and an instructions block, and nothing else. In the harness scenario run for #3748 (Antigravity CLI 1.3.4, the skill and block as the installer writes them):

  • the probe named the project from the workspace folder's name (widget), not from the graph, and said "unknown" for the skills available;
  • a skill edited mid-session was not noticed: asked whether anything about how work is done had changed, the session answered "No", citing the earlier read of the standard;
  • the session did not reach the case of a task finished elsewhere, so it is not measured for Antigravity; the Codex and Claude Code plugins refuse the next write in it.

Why a plugin is possible

Checked against Antigravity CLI 1.3.4 with a logging hook in a scratch workspace, and the hooks documentation (https://antigravity.google/docs/hooks):

Plugin duty (ADR-093) Antigravity hook
Session-start check, project resolution, orientation, skill list SessionStart: injectSteps with a systemMessage or ephemeralMessage
Note when the skill list changes PreInvocation (there is no user-prompt event): injectSteps before each model invocation
Refuse tool calls once the watched item is finished elsewhere PreToolUse: {"decision": "deny", "reason": ...} for run_command and the file-edit tools
Status None found

Observed:

  • A workspace .agents/hooks.json (and ~/.gemini/config/hooks.json) runs hooks in print mode. The payload carries conversationId, workspacePaths, toolCall.name (run_command) and toolCall.args.CommandLine.
  • ANTIGRAVITY_CONVERSATION_ID (the same id) is in the environment of the agent's own shell commands, so the CLI can name a write journal after it, as it does for CODEX_THREAD_ID.
  • Hooks are commands, one process per event: the session state has to be kept in a file per conversation, as for Codex (plugins/codex/hook.ts, createSession(host, interval, state) and snapshot() in the shared module).
  • PreToolUse must answer with a decision; a hook that prints {} denies the call. PostToolUse must answer exactly {}: any other field makes Antigravity abort the tool call.
  • PostToolUse carries the tool call and an error, with no tool output documented. The shared module learns the item being worked on from a command's output (nodespace query run --with-context), so that case needs the hook to run the read itself, or to read the transcript at transcriptPath.
  • Antigravity has agy plugin install/validate and can import Claude Code plugins (agy plugin import claude): the packaging format is the open question.

Acceptance criteria

  • nodespace skill install antigravity gives Antigravity hooks (or a plugin) in addition to the skill and block; nodespace uninstall removes them.
  • A session in a checkout of a known project receives the project, orientation, consent rules and skill list without asking.
  • A skill edited mid-session is announced on the next invocation.
  • Once the task being worked on is finished elsewhere, the next shell command or file edit is refused with the reason.
  • Write attribution works: the session's own writes are not read as foreign (the CLI names the journal after ANTIGRAVITY_CONVERSATION_ID, or the hook rewrites the command).
  • Whether the hooks need user trust is settled and the installer says what the user has to do.
  • The scenario in scripts/eval/harness/ is run with the plugin, and the Antigravity column compared with the baseline above.

Refs #3748

Activity

  1. self-assigned this
    on Oct 13, 2026
  2. malibio commented on Oct 13, 2026

    @malibio
    CollaboratorAuthor

    Baseline: packages/skill 285 passed. Starting from the Codex hooks (plugins/codex/hook.ts) as the model.

  3. malibio commented on Oct 13, 2026

    @malibio
    CollaboratorAuthor

    Antigravity column, with the hooks (PR #3802)

    Antigravity CLI 1.3.4, the skill and block as installed, the hooks this checkout's installer writes, isolated daemon, #3748's fixture. The first prompt makes the user's choice of task and the second names the task the scenario finishes (the implementing skill's first step is that the user chooses the work; without it the baseline stopped to ask, and so did the first run with the hooks). The watch interval is 3 seconds for this driver: the agent reads the finished task within seconds.

    Case Baseline (no hooks) With the hooks
    Probe: project and skill list known with no command No: project guessed from the folder name, skills "unknown" Yes: project and its id, the skills and the standard named
    Skill edited mid-session is announced No: answered "No", citing its earlier read Yes: named the standard and its new description
    Task finished elsewhere stops the session Not reached: stopped to ask which task Yes: the next call was refused, tool call denied by pre-tool hook: [NodeSpace] The item ... changed under it: it went from version 1 to 4, and the agent stopped and wrote nothing more
    Own writes not mistaken for foreign Not applicable Yes: its own version 2 was accounted for; only 3 and 4 were reported (the CLI names the journal after ANTIGRAVITY_CONVERSATION_ID)
    Status line None None: Antigravity has no place for it

    Facts found by running it, in the README's Antigravity section: injectSteps systemMessage is nested and reaches the agent; invocationNum is 0 for the first model call after each user message, so it is the prompt; SessionStart does not fire when a conversation is continued; a PostToolUse hook must answer {} and carries no output, so a nodespace command's output is read from the transcript; allow leaves the permission system to decide; no trust step is needed for hooks.

    Not checked: Antigravity's hook shell on Windows (the command is the POSIX form Codex uses), and the told comparison on a session NodeSpace launched (covered by a process-level test, not a live run).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions