@didim365/agent-cli-core 0.1.1 → 0.1.3

package/dist/docs/hooks/index.md

@@ -1,178 +0,0 @@
-# Gemini CLI hooks (experimental)
-
-Hooks are scripts or programs that Gemini CLI executes at specific points in the
-agentic loop, allowing you to intercept and customize behavior without modifying
-the CLI's source code.
-
-## Availability
-
-> **Experimental Feature**: Hooks are currently enabled by default only in the
-> **Preview** and **Nightly** release channels.
-
-If you are on the Stable channel, you must explicitly enable the hooks system in
-your `settings.json`:
-
-```json
-{
-  "hooksConfig": {
-    "enabled": true
-  }
-}
-```
-
-- **[Writing hooks guide](/docs/hooks/writing-hooks)**: A tutorial on creating
-  your first hook with comprehensive examples.
-- **[Hooks reference](/docs/hooks/reference)**: The definitive technical
-  specification of I/O schemas and exit codes.
-- **[Best practices](/docs/hooks/best-practices)**: Guidelines on security,
-  performance, and debugging.
-
-## What are hooks?
-
-Hooks run synchronously as part of the agent loop—when a hook event fires,
-Gemini CLI waits for all matching hooks to complete before continuing.
-
-With hooks, you can:
-
-- **Add context:** Inject relevant information (like git history) before the
-  model processes a request.
-- **Validate actions:** Review tool arguments and block potentially dangerous
-  operations.
-- **Enforce policies:** Implement security scanners and compliance checks.
-- **Log interactions:** Track tool usage and model responses for auditing.
-- **Optimize behavior:** Dynamically filter available tools or adjust model
-  parameters.
-
-## Core concepts
-
-### Hook events
-
-Hooks are triggered by specific events in Gemini CLI's lifecycle.
-
-| Event                 | When It Fires                                  | Impact                 | Common Use Cases                             |
-| --------------------- | ---------------------------------------------- | ---------------------- | -------------------------------------------- |
-| `SessionStart`        | When a session begins (startup, resume, clear) | Inject Context         | Initialize resources, load context           |
-| `SessionEnd`          | When a session ends (exit, clear)              | Advisory               | Clean up, save state                         |
-| `BeforeAgent`         | After user submits prompt, before planning     | Block Turn / Context   | Add context, validate prompts, block turns   |
-| `AfterAgent`          | When agent loop ends                           | Retry / Halt           | Review output, force retry or halt execution |
-| `BeforeModel`         | Before sending request to LLM                  | Block Turn / Mock      | Modify prompts, swap models, mock responses  |
-| `AfterModel`          | After receiving LLM response                   | Block Turn / Redact    | Filter/redact responses, log interactions    |
-| `BeforeToolSelection` | Before LLM selects tools                       | Filter Tools           | Filter available tools, optimize selection   |
-| `BeforeTool`          | Before a tool executes                         | Block Tool / Rewrite   | Validate arguments, block dangerous ops      |
-| `AfterTool`           | After a tool executes                          | Block Result / Context | Process results, run tests, hide results     |
-| `PreCompress`         | Before context compression                     | Advisory               | Save state, notify user                      |
-| `Notification`        | When a system notification occurs              | Advisory               | Forward to desktop alerts, logging           |
-
-### Global mechanics
-
-Understanding these core principles is essential for building robust hooks.
-
-#### Strict JSON requirements (The "Golden Rule")
-
-Hooks communicate via `stdin` (Input) and `stdout` (Output).
-
-1. **Silence is Mandatory**: Your script **must not** print any plain text to
-   `stdout` other than the final JSON object. **Even a single `echo` or `print`
-   call before the JSON will break parsing.**
-2. **Pollution = Failure**: If `stdout` contains non-JSON text, parsing will
-   fail. The CLI will default to "Allow" and treat the entire output as a
-   `systemMessage`.
-3. **Debug via Stderr**: Use `stderr` for **all** logging and debugging (e.g.,
-   `echo "debug" >&2`). Gemini CLI captures `stderr` but never attempts to parse
-   it as JSON.
-
-#### Exit codes
-
-Gemini CLI uses exit codes to determine the high-level outcome of a hook
-execution:
-
-| Exit Code | Label            | Behavioral Impact                                                                                                                                                            |
-| --------- | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **0**     | **Success**      | The `stdout` is parsed as JSON. **Preferred code** for all logic, including intentional blocks (e.g., `{"decision": "deny"}`).                                               |
-| **2**     | **System Block** | **Critical Block**. The target action (tool, turn, or stop) is aborted. `stderr` is used as the rejection reason. High severity; used for security stops or script failures. |
-| **Other** | **Warning**      | Non-fatal failure. A warning is shown, but the interaction proceeds using original parameters.                                                                               |
-
-#### Matchers
-
-You can filter which specific tools or triggers fire your hook using the
-`matcher` field.
-
-- **Tool events** (`BeforeTool`, `AfterTool`): Matchers are **Regular
-  Expressions**. (e.g., `"write_.*"`).
-- **Lifecycle events**: Matchers are **Exact Strings**. (e.g., `"startup"`).
-- **Wildcards**: `"*"` or `""` (empty string) matches all occurrences.
-
-## Configuration
-
-Hooks are configured in `settings.json`. Gemini CLI merges configurations from
-multiple layers in the following order of precedence (highest to lowest):
-
-1.  **Project settings**: `.gemini/settings.json` in the current directory.
-2.  **User settings**: `~/.gemini/settings.json`.
-3.  **System settings**: `/etc/gemini-cli/settings.json`.
-4.  **Extensions**: Hooks defined by installed extensions.
-
-### Configuration schema
-
-```json
-{
-  "hooks": {
-    "BeforeTool": [
-      {
-        "matcher": "write_file|replace",
-        "hooks": [
-          {
-            "name": "security-check",
-            "type": "command",
-            "command": "$GEMINI_PROJECT_DIR/.gemini/hooks/security.sh",
-            "timeout": 5000
-          }
-        ]
-      }
-    ]
-  }
-}
-```
-
-#### Hook configuration fields
-
-| Field         | Type   | Required  | Description                                                          |
-| :------------ | :----- | :-------- | :------------------------------------------------------------------- |
-| `type`        | string | **Yes**   | The execution engine. Currently only `"command"` is supported.       |
-| `command`     | string | **Yes\*** | The shell command to execute. (Required when `type` is `"command"`). |
-| `name`        | string | No        | A friendly name for identifying the hook in logs and CLI commands.   |
-| `timeout`     | number | No        | Execution timeout in milliseconds (default: 60000).                  |
-| `description` | string | No        | A brief explanation of the hook's purpose.                           |
-
----
-
-### Environment variables
-
-Hooks are executed with a sanitized environment.
-
-- `GEMINI_PROJECT_DIR`: The absolute path to the project root.
-- `GEMINI_SESSION_ID`: The unique ID for the current session.
-- `GEMINI_CWD`: The current working directory.
-- `CLAUDE_PROJECT_DIR`: (Alias) Provided for compatibility.
-
-## Security and risks
-
-> **Warning: Hooks execute arbitrary code with your user privileges.** By
-> configuring hooks, you are allowing scripts to run shell commands on your
-> machine.
-
-**Project-level hooks** are particularly risky when opening untrusted projects.
-Gemini CLI **fingerprints** project hooks. If a hook's name or command changes
-(e.g., via `git pull`), it is treated as a **new, untrusted hook** and you will
-be warned before it executes.
-
-See [Security Considerations](/docs/hooks/best-practices#using-hooks-securely)
-for a detailed threat model.
-
-## Managing hooks
-
-Use the CLI commands to manage hooks without editing JSON manually:
-
-- **View hooks:** `/hooks panel`
-- **Enable/Disable all:** `/hooks enable-all` or `/hooks disable-all`
-- **Toggle individual:** `/hooks enable <name>` or `/hooks disable <name>`

package/dist/docs/hooks/reference.md

@@ -1,322 +0,0 @@
-# Hooks reference
-
-This document provides the technical specification for Gemini CLI hooks,
-including JSON schemas and API details.
-
-## Global hook mechanics
-
-- **Communication**: `stdin` for Input (JSON), `stdout` for Output (JSON), and
-  `stderr` for logs and feedback.
-- **Exit codes**:
-  - `0`: Success. `stdout` is parsed as JSON. **Preferred for all logic.**
-  - `2`: System Block. The action is blocked; `stderr` is used as the rejection
-    reason.
-  - `Other`: Warning. A non-fatal failure occurred; the CLI continues with a
-    warning.
-- **Silence is Mandatory**: Your script **must not** print any plain text to
-  `stdout` other than the final JSON.
-
----
-
-## Configuration schema
-
-Hooks are defined in `settings.json` within the `hooks` object. Each event
-(e.g., `BeforeTool`) contains an array of **hook definitions**.
-
-### Hook definition
-
-| Field        | Type      | Required | Description                                                                             |
-| :----------- | :-------- | :------- | :-------------------------------------------------------------------------------------- |
-| `matcher`    | `string`  | No       | A regex (for tools) or exact string (for lifecycle) to filter when the hook runs.       |
-| `sequential` | `boolean` | No       | If `true`, hooks in this group run one after another. If `false`, they run in parallel. |
-| `hooks`      | `array`   | **Yes**  | An array of **hook configurations**.                                                    |
-
-### Hook configuration
-
-| Field         | Type     | Required  | Description                                                          |
-| :------------ | :------- | :-------- | :------------------------------------------------------------------- |
-| `type`        | `string` | **Yes**   | The execution engine. Currently only `"command"` is supported.       |
-| `command`     | `string` | **Yes\*** | The shell command to execute. (Required when `type` is `"command"`). |
-| `name`        | `string` | No        | A friendly name for identifying the hook in logs and CLI commands.   |
-| `timeout`     | `number` | No        | Execution timeout in milliseconds (default: 60000).                  |
-| `description` | `string` | No        | A brief explanation of the hook's purpose.                           |
-
----
-
-## Base input schema
-
-All hooks receive these common fields via `stdin`:
-
-```typescript
-{
-  "session_id": string,      // Unique ID for the current session
-  "transcript_path": string, // Absolute path to session transcript JSON
-  "cwd": string,             // Current working directory
-  "hook_event_name": string, // The firing event (e.g. "BeforeTool")
-  "timestamp": string        // ISO 8601 execution time
-}
-```
-
----
-
-## Common output fields
-
-Most hooks support these fields in their `stdout` JSON:
-
-| Field            | Type      | Description                                                                    |
-| :--------------- | :-------- | :----------------------------------------------------------------------------- |
-| `systemMessage`  | `string`  | Displayed immediately to the user in the terminal.                             |
-| `suppressOutput` | `boolean` | If `true`, hides internal hook metadata from logs/telemetry.                   |
-| `continue`       | `boolean` | If `false`, stops the entire agent loop immediately.                           |
-| `stopReason`     | `string`  | Displayed to the user when `continue` is `false`.                              |
-| `decision`       | `string`  | `"allow"` or `"deny"` (alias `"block"`). Specific impact depends on the event. |
-| `reason`         | `string`  | The feedback/error message provided when a `decision` is `"deny"`.             |
-
----
-
-## Tool hooks
-
-### Matchers and tool names
-
-For `BeforeTool` and `AfterTool` events, the `matcher` field in your settings is
-compared against the name of the tool being executed.
-
-- **Built-in Tools**: You can match any built-in tool (e.g., `read_file`,
-  `run_shell_command`). See the [Tools Reference](/docs/tools) for a full list
-  of available tool names.
-- **MCP Tools**: Tools from MCP servers follow the naming pattern
-  `mcp__<server_name>__<tool_name>`.
-- **Regex Support**: Matchers support regular expressions (e.g.,
-  `matcher: "read_.*"` matches all file reading tools).
-
-### `BeforeTool`
-
-Fires before a tool is invoked. Used for argument validation, security checks,
-and parameter rewriting.
-
-- **Input Fields**:
-  - `tool_name`: (`string`) The name of the tool being called.
-  - `tool_input`: (`object`) The raw arguments generated by the model.
-  - `mcp_context`: (`object`) Optional metadata for MCP-based tools.
-- **Relevant Output Fields**:
-  - `decision`: Set to `"deny"` (or `"block"`) to prevent the tool from
-    executing.
-  - `reason`: Required if denied. This text is sent **to the agent** as a tool
-    error, allowing it to respond or retry.
-  - `hookSpecificOutput.tool_input`: An object that **merges with and
-    overrides** the model's arguments before execution.
-  - `continue`: Set to `false` to **kill the entire agent loop** immediately.
-- **Exit Code 2 (Block Tool)**: Prevents execution. Uses `stderr` as the
-  `reason` sent to the agent. **The turn continues.**
-
-### `AfterTool`
-
-Fires after a tool executes. Used for result auditing, context injection, or
-hiding sensitive output from the agent.
-
-- **Input Fields**:
-  - `tool_name`: (`string`)
-  - `tool_input`: (`object`) The original arguments.
-  - `tool_response`: (`object`) The result containing `llmContent`,
-    `returnDisplay`, and optional `error`.
-  - `mcp_context`: (`object`)
-- **Relevant Output Fields**:
-  - `decision`: Set to `"deny"` to hide the real tool output from the agent.
-  - `reason`: Required if denied. This text **replaces** the tool result sent
-    back to the model.
-  - `hookSpecificOutput.additionalContext`: Text that is **appended** to the
-    tool result for the agent.
-  - `continue`: Set to `false` to **kill the entire agent loop** immediately.
-- **Exit Code 2 (Block Result)**: Hides the tool result. Uses `stderr` as the
-  replacement content sent to the agent. **The turn continues.**
-
----
-
-## Agent hooks
-
-### `BeforeAgent`
-
-Fires after a user submits a prompt, but before the agent begins planning. Used
-for prompt validation or injecting dynamic context.
-
-- **Input Fields**:
-  - `prompt`: (`string`) The original text submitted by the user.
-- **Relevant Output Fields**:
-  - `hookSpecificOutput.additionalContext`: Text that is **appended** to the
-    prompt for this turn only.
-  - `decision`: Set to `"deny"` to block the turn and **discard the user's
-    message** (it will not appear in history).
-  - `continue`: Set to `false` to block the turn but **save the message to
-    history**.
-  - `reason`: Required if denied or stopped.
-- **Exit Code 2 (Block Turn)**: Aborts the turn and erases the prompt from
-  context. Same as `decision: "deny"`.
-
-### `AfterAgent`
-
-Fires once per turn after the model generates its final response. Primary use
-case is response validation and automatic retries.
-
-- **Input Fields**:
-  - `prompt`: (`string`) The user's original request.
-  - `prompt_response`: (`string`) The final text generated by the agent.
-  - `stop_hook_active`: (`boolean`) Indicates if this hook is already running as
-    part of a retry sequence.
-- **Relevant Output Fields**:
-  - `decision`: Set to `"deny"` to **reject the response** and force a retry.
-  - `reason`: Required if denied. This text is sent **to the agent as a new
-    prompt** to request a correction.
-  - `continue`: Set to `false` to **stop the session** without retrying.
-  - `clearContext`: If `true`, clears conversation history (LLM memory) while
-    preserving UI display.
-- **Exit Code 2 (Retry)**: Rejects the response and triggers an automatic retry
-  turn using `stderr` as the feedback prompt.
-
----
-
-## Model hooks
-
-### `BeforeModel`
-
-Fires before sending a request to the LLM. Operates on a stable, SDK-agnostic
-request format.
-
-- **Input Fields**:
-  - `llm_request`: (`object`) Contains `model`, `messages`, and `config`
-    (generation params).
-- **Relevant Output Fields**:
-  - `hookSpecificOutput.llm_request`: An object that **overrides** parts of the
-    outgoing request (e.g., changing models or temperature).
-  - `hookSpecificOutput.llm_response`: A **Synthetic Response** object. If
-    provided, the CLI skips the LLM call entirely and uses this as the response.
-  - `decision`: Set to `"deny"` to block the request and abort the turn.
-- **Exit Code 2 (Block Turn)**: Aborts the turn and skips the LLM call. Uses
-  `stderr` as the error message.
-
-### `BeforeToolSelection`
-
-Fires before the LLM decides which tools to call. Used to filter the available
-toolset or force specific tool modes.
-
-- **Input Fields**:
-  - `llm_request`: (`object`) Same format as `BeforeModel`.
-- **Relevant Output Fields**:
-  - `hookSpecificOutput.toolConfig.mode`: (`"AUTO" | "ANY" | "NONE"`)
-    - `"NONE"`: Disables all tools (Wins over other hooks).
-    - `"ANY"`: Forces at least one tool call.
-  - `hookSpecificOutput.toolConfig.allowedFunctionNames`: (`string[]`) Whitelist
-    of tool names.
-- **Union Strategy**: Multiple hooks' whitelists are **combined**.
-- **Limitations**: Does **not** support `decision`, `continue`, or
-  `systemMessage`.
-
-### `AfterModel`
-
-Fires immediately after an LLM response chunk is received. Used for real-time
-redaction or PII filtering.
-
-- **Input Fields**:
-  - `llm_request`: (`object`) The original request.
-  - `llm_response`: (`object`) The model's response (or a single chunk during
-    streaming).
-- **Relevant Output Fields**:
-  - `hookSpecificOutput.llm_response`: An object that **replaces** the model's
-    response chunk.
-  - `decision`: Set to `"deny"` to discard the response chunk and block the
-    turn.
-  - `continue`: Set to `false` to **kill the entire agent loop** immediately.
-- **Note on Streaming**: Fired for **every chunk** generated by the model.
-  Modifying the response only affects the current chunk.
-- **Exit Code 2 (Block Response)**: Aborts the turn and discards the model's
-  output. Uses `stderr` as the error message.
-
----
-
-## Lifecycle & system hooks
-
-### `SessionStart`
-
-Fires on application startup, resuming a session, or after a `/clear` command.
-Used for loading initial context.
-
-- **Input fields**:
-  - `source`: (`"startup" | "resume" | "clear"`)
-- **Relevant output fields**:
-  - `hookSpecificOutput.additionalContext`: (`string`)
-    - **Interactive**: Injected as the first turn in history.
-    - **Non-interactive**: Prepended to the user's prompt.
-  - `systemMessage`: Shown at the start of the session.
-- **Advisory only**: `continue` and `decision` fields are **ignored**. Startup
-  is never blocked.
-
-### `SessionEnd`
-
-Fires when the CLI exits or a session is cleared. Used for cleanup or final
-telemetry.
-
-- **Input Fields**:
-  - `reason`: (`"exit" | "clear" | "logout" | "prompt_input_exit" | "other"`)
-- **Relevant Output Fields**:
-  - `systemMessage`: Displayed to the user during shutdown.
-- **Best Effort**: The CLI **will not wait** for this hook to complete and
-  ignores all flow-control fields (`continue`, `decision`).
-
-### `Notification`
-
-Fires when the CLI emits a system alert (e.g., Tool Permissions). Used for
-external logging or cross-platform alerts.
-
-- **Input Fields**:
-  - `notification_type`: (`"ToolPermission"`)
-  - `message`: Summary of the alert.
-  - `details`: JSON object with alert-specific metadata (e.g., tool name, file
-    path).
-- **Relevant Output Fields**:
-  - `systemMessage`: Displayed alongside the system alert.
-- **Observability Only**: This hook **cannot** block alerts or grant permissions
-  automatically. Flow-control fields are ignored.
-
-### `PreCompress`
-
-Fires before the CLI summarizes history to save tokens. Used for logging or
-state saving.
-
-- **Input Fields**:
-  - `trigger`: (`"auto" | "manual"`)
-- **Relevant Output Fields**:
-  - `systemMessage`: Displayed to the user before compression.
-- **Advisory Only**: Fired asynchronously. It **cannot** block or modify the
-  compression process. Flow-control fields are ignored.
-
----
-
-## Stable Model API
-
-Gemini CLI uses these structures to ensure hooks don't break across SDK updates.
-
-**LLMRequest**:
-
-```typescript
-{
-  "model": string,
-  "messages": Array<{
-    "role": "user" | "model" | "system",
-    "content": string // Non-text parts are filtered out for hooks
-  }>,
-  "config": { "temperature": number, ... },
-  "toolConfig": { "mode": string, "allowedFunctionNames": string[] }
-}
-
-```
-
-**LLMResponse**:
-
-```typescript
-{
-  "candidates": Array<{
-    "content": { "role": "model", "parts": string[] },
-    "finishReason": string
-  }>,
-  "usageMetadata": { "totalTokenCount": number }
-}
-```