@globant/coda-linux-arm64 1.3.0 → 1.5.0

package/assets/skills/configure-mcp/SKILL.md

@@ -0,0 +1,281 @@
+---
+name: configure-mcp
+description: Configure g-coda's MCP client to connect to an MCP server from a Git URL, remote HTTP endpoint, or npm/pip package, at project or global scope. Use when the user asks to add, register, configure, install, or set up an MCP server or MCP client. e.g. "add the playwright MCP server", "configure an MCP server from this URL", "install this MCP tool globally".
+---
+
+# Configure MCP
+
+Configure g-coda's MCP client to connect to an MCP server by registering the server entry in the correct config file at the user-chosen scope. The input can be a Git URL, remote HTTP endpoint, or npm/pip package. Reject inputs from which no valid transport (`command` or `url`) can be derived — write nothing in that case.
+
+---
+
+## Golden Rule
+
+**Never overwrite existing server entries.** Always merge your new entry into the existing `mcpServers` object. If a server with the same name already exists, confirm with the user before replacing it.
+
+**Never hardcode secrets.** Tokens, API keys, and credentials must use `${VAR}` or `${VAR:-default}` interpolation — never inline values. A default is literal text up to the first `}`; it cannot contain another `${…}` reference (no `${A:-${B}}`) or a line break.
+
+---
+
+## Step 1: Determine Scope
+
+Ask the user which scope they want if not specified:
+
+| Scope | Write to | When to use |
+|---|---|---|
+| **Project** | `<cwd>/.coda/mcp.json` | Only this repo; shared via version control |
+| **Global** | `~/.coda/mcp.json` | All projects on this machine; personal |
+
+- `<cwd>` = `process.cwd()` where g-coda is running, not the nearest `.git` root.
+- If unsure, **default to project scope**.
+- A project entry always wins over a global entry with the same server name.
+
+**Target file:** always write to `mcp.json` (top-level `mcpServers` key).
+
+---
+
+## Step 2: Detect Input Type and Validate
+
+### 2a. Remote HTTP endpoint
+
+Input is `https://…` or `http://…` pointing to a live MCP endpoint (Streamable HTTP transport).
+
+Example entry — replace the URL, token variable name, and header values with the real ones:
+
+```jsonc
+{
+  "url": "https://api.example.com/mcp",
+  "authorizationToken": "Bearer ${API_TOKEN}",
+  "headers": { "X-Custom": "${CUSTOM_HEADER}" },
+  "timeout": 120
+}
+```
+
+> ⚠️ Make sure no tokens or secrets are exposed — always use `${VAR}` interpolation for credentials.
+
+Transport: `url` → HTTP. Do **not** set `command`.
+
+### 2b. npm/pip package or CLI tool
+
+Input is a package name, `npx`/`uvx` invocation, or local binary path (stdio transport).
+
+Example entry — replace the package name and env var names with the real ones:
+
+```jsonc
+{
+  "command": "npx",
+  "args": ["-y", "@scope/mcp-package@latest"],
+  "env": { "API_KEY": "${MY_API_KEY}" }
+}
+```
+
+> ⚠️ Make sure no tokens or secrets are exposed — always use `${VAR}` interpolation for credentials.
+
+Common patterns: `npx -y <pkg>`, `uvx <pkg>`, `node /path/to/server.js`, `/path/to/binary`.
+
+Transport: `command` → stdio. Do **not** set `url`.
+
+### 2c. Git URL
+
+Most MCP server repositories support **multiple installation methods** (e.g. `npx`, `uvx`, Docker, a remote HTTP endpoint, or a local build). Do not assume — read the repo's documentation first, then ask the user which method they prefer.
+
+Steps:
+
+1. **Clone temporarily** to read the docs:
+   - Project scope: `<cwd>/.coda/tmp/<name>/`
+   - Global scope: `~/.coda/tmp/<name>/`
+   - Command: `git clone --depth 1 <url> <tmp-dir>`
+2. **Read the README and any MCP-specific docs** to identify all available installation methods.
+3. **Ask the user** which method they prefer — present the options you found. Common options:
+   - `npx -y <pkg>` or `uvx <pkg>` (no local build needed — preferred when available)
+   - Remote HTTP endpoint (if the project exposes one)
+   - Local build (`npm install && npm run build`, entry via `node dist/index.js`)
+4. **Derive the entry** using the chosen method (see sections 2a and 2b for the corresponding entry shape).
+5. **Write the config entry** to `mcp.json`.
+6. **Delete the temporary clone** (`<tmp-dir>`) — it is no longer needed once the config entry is written.
+
+> If the chosen method does not require the cloned directory at runtime (e.g. `npx`/`uvx`/HTTP), the tmp directory is always safe to remove. If the user explicitly chooses a local-build method and the runtime depends on the clone, move the directory to its final location (`<cwd>/.coda/mcp-servers/<name>/` or `~/.coda/mcp-servers/<name>/`) instead of deleting it, and tell the user.
+
+### 2d. Rejection — no derivable transport
+
+If you **cannot** determine either a `command` or a `url` from the input, **do not write anything**. Respond:
+
+> "I couldn't determine a valid MCP server transport from what you provided. An MCP server needs either a runnable command (for stdio transport) or an HTTP URL (for Streamable HTTP transport). Please share the server's npm package name, a Git URL, a binary path, or its HTTP endpoint."
+
+---
+
+## Step 3: Build the Server Entry
+
+A valid entry has **exactly one** of `command` (stdio) or `url` (http) — never both, never neither.
+
+| Field | Transport | Description |
+|---|---|---|
+| `command` | stdio | Executable to run as a subprocess |
+| `args` | stdio | Arguments for the subprocess |
+| `cwd` | stdio | Working directory for the subprocess |
+| `url` | http | MCP server HTTP endpoint |
+| `authorizationToken` | http | Shorthand `Authorization` header; supports `${VAR}` |
+| `oauth` | http | `true` for an OAuth 2.1 server; the user signs in with `coda mcp login <name>` |
+| `oauthClientId` | http | Pre-registered OAuth client id, for servers without dynamic client registration (Glob.AI: `mcp`); requires `oauth: true` |
+| `headers` | http | Extra request headers; string values support `${VAR}` |
+| `timeout` | both | Timeout in seconds for each request to the server; unset means 60 s for MCP requests and 30 s for OAuth sign-in requests |
+| `env` | both | Environment variables; supports `${VAR}` and `${VAR:-default}` |
+| `disabled` | both | `true` to skip at load time (default: `false`) |
+
+Secrets in `env`, `headers`, and `authorizationToken` are resolved from `~/.coda/.secrets`, project `.env`, and `process.env` at load time. Never put raw credentials in the config.
+
+Choose a descriptive, kebab-case server name (e.g., `playwright`, `github`, `my-internal-api`).
+
+---
+
+## Step 4: Non-Destructive Merge into Config
+
+### Writing to `mcp.json` (preferred)
+
+```jsonc
+// <cwd>/.coda/mcp.json  (project)  or  ~/.coda/mcp.json  (global)
+{
+  "mcpServers": {
+    "<server-name>": { /* entry fields */ }
+  }
+}
+```
+
+Merge steps:
+1. Read the existing file, or start with `{ "mcpServers": {} }` if absent.
+2. Check whether `mcpServers["<server-name>"]` exists — confirm with the user before replacing.
+3. Add or replace only the target key; preserve all other entries.
+4. Write the file back.
+
+---
+
+## Step 5: Verify and Notify
+
+After writing:
+
+1. Show the user exactly what was written (entry + file path).
+2. Confirm the file is valid JSON (no trailing commas, balanced braces).
+3. Remind the user how to activate the change:
+
+> **MCP changes are not picked up by `/skills refresh`.** To activate:
+> - Run `/mcp` → select **Reload MCP servers**, or
+> - Restart g-coda.
+
+4. For cloned Git repos, delete the temporary directory (`<cwd>/.coda/tmp/<name>/` or `~/.coda/tmp/<name>/`) once the config entry has been written — unless the user chose a local-build method that requires the directory at runtime, in which case it was already moved to its final location as part of step 2c.
+
+---
+
+## Examples
+
+### Example 1 — npm package, project scope
+
+**User:** "Add the Playwright MCP server to this project."
+
+Written to `<cwd>/.coda/mcp.json`:
+```json
+{
+  "mcpServers": {
+    "playwright": {
+      "command": "npx",
+      "args": ["-y", "@playwright/mcp@latest"]
+    }
+  }
+}
+```
+
+**Response:** Added `playwright` to `.coda/mcp.json`. Run `/mcp` → Reload MCP servers to activate it.
+
+---
+
+### Example 2 — HTTP endpoint, global scope, with auth
+
+**User:** "Set up the GitHub MCP server globally. My token is in `GITHUB_TOKEN`."
+
+Written to `~/.coda/mcp.json`:
+```json
+{
+  "mcpServers": {
+    "github": {
+      "url": "https://api.githubcopilot.com/mcp/",
+      "authorizationToken": "Bearer ${GITHUB_TOKEN}",
+      "timeout": 120
+    }
+  }
+}
+```
+
+**Response:** Added `github` to `~/.coda/mcp.json`. Make sure `GITHUB_TOKEN` is set in your environment or `~/.coda/.secrets`. Run `/mcp` → Reload MCP servers to activate it.
+
+---
+
+### Example 3 — Git URL, project scope
+
+**User:** "Install from https://github.com/example/my-mcp-server into this project."
+
+Steps:
+1. Clone to `<cwd>/.coda/tmp/my-mcp-server/` with `git clone --depth 1 <url> <tmp-dir>`.
+2. Read `README.md` — it documents two options: `npx -y @example/my-mcp-server` or a local build.
+3. Ask the user: *"The repository supports `npx` (no local build needed) or a local build. Which do you prefer?"*
+4. User chooses `npx`. Derive the entry (section 2b).
+5. Write config, then delete `<cwd>/.coda/tmp/my-mcp-server/`.
+
+Written to `<cwd>/.coda/mcp.json`:
+```json
+{
+  "mcpServers": {
+    "my-mcp-server": {
+      "command": "npx",
+      "args": ["-y", "@example/my-mcp-server@latest"]
+    }
+  }
+}
+```
+
+**Response:** Added `my-mcp-server` to `.coda/mcp.json` and removed the temporary clone. Run `/mcp` → Reload MCP servers to activate it.
+
+---
+
+### Example 4 — Rejection
+
+**User:** "Add `my-special-tool` as an MCP server."
+
+No URL or command is derivable from the name alone.
+
+**Response:** I couldn't determine a valid MCP server transport for `my-special-tool`. Please share the npm package name, a Git URL, a binary path, or the HTTP endpoint.
+
+---
+
+## Error Handling
+
+| Situation | Action |
+|---|---|
+| File exists but is invalid JSON | Report the parse error and path; do not overwrite. Ask user to fix manually. |
+| Server name already exists | Show the existing entry; ask user to confirm replacement. |
+| No transport derivable | Reject with a clear explanation (Step 2d). Do not write anything. |
+| Git clone fails | Report the error and path; do not write a config entry. Clean up any partial tmp directory. |
+| No installation method found in repo docs | Tell the user no clear method was found; ask them to provide the command or URL directly. |
+| Secret value unclear | Ask which env var name to use; never guess a value. |
+
+---
+
+## Instructions for the Agent
+
+1. **Clarify scope first** — ask project vs global if not stated. Default to project.
+2. **Derive the entry** — HTTP URL → `url` field; package/git/binary → `command` field. For Git URLs, clone to a tmp dir, read the docs, ask the user which method to use, then delete the tmp dir. If no transport is derivable, reject immediately (do not write).
+3. **Choose the config file** — always use `mcp.json` (top-level `mcpServers` key).
+4. **Merge non-destructively** — read the existing file first; preserve all other entries.
+5. **No inline secrets** — always use `${VAR}` notation; tell the user which env var to set.
+6. **Validate JSON** — ensure the written file is syntactically valid.
+7. **Remind about reload** — MCP changes need `/mcp` → Reload MCP servers or a restart. `/skills refresh` does NOT reload MCP.
+8. **Show the result** — always display the final entry and the full path of the file written.
+
+---
+
+## Deliverables
+
+When done, provide:
+
+1. The exact file path written (e.g., `<cwd>/.coda/mcp.json` or `~/.coda/mcp.json`).
+2. The server entry that was added (JSON block).
+3. Any env vars the user needs to set (if secrets are involved).
+4. The activation command: `/mcp` → Reload MCP servers (or restart g-coda).

package/assets/skills/create-hook/SKILL.md

@@ -65,7 +65,7 @@ Spawns a shell command via `sh -c`. g-coda writes a JSON payload to the command'
 | `command` | string | required | Shell command to run |
 | `args` | string[] | — | Extra arguments appended to the command |
 | `timeout` | number | 600 | Seconds before the hook is killed |
-| `shell` | `"bash"` \| `"powershell"` | system default | Shell to use |
+| `shell` | `"sh"` \| `"bash"` \| `"powershell"` \| `"auto"` | `"auto"` (POSIX-first: `sh` on macOS/Linux, Git Bash on Windows, PowerShell as a last resort) | Shell to use |
 | `statusMessage` | string | — | Spinner text shown while the hook runs |
 | `if` | string | — | Conditional expression (tool events only) |
 
@@ -154,15 +154,15 @@ Every hook receives a JSON object on stdin. All events include these base fields
 ```json
 {
   "session_id": "abc123",
-  "transcript_path": "/path/to/transcript.json",
+  "transcript_path": "",
   "cwd": "/path/to/project",
   "hook_event_name": "PreToolUse",
-  "permission_mode": "default",
-  "agent_id": "...",
-  "agent_type": "main"
+  "cli_version": "0.4.2"
 }
 ```
 
+`transcript_path` is always an empty string (Coda persists conversations to a database, not a transcript file; the field exists for wire-compatibility). `cli_version` is the running Coda version — also available to command hooks as the `CODA_VERSION` env var, which is cheaper than parsing stdin in hot-path hooks. `permission_mode`, `agent_id`, and `agent_type` are reserved fields that are currently never populated — do not depend on them.
+
 Additional fields by event:
 
 **Tool events** (`PreToolUse`, `PostToolUse`, `PostToolUseFailure`):

package/assets/skills/init-rules/SKILL.md

@@ -17,6 +17,8 @@ This skill assumes the session is running in **auto mode** (unattended/hands-off
 
 If the user is not in auto mode, still proceed — the rules are valid in any mode — but note that in `default`/`read-only` mode many commands already require approval, so `deny`/`ask` rules matter most.
 
+Keeping auto after the rules land: on a fresh install the silent `auto` default applies to the current session only, and only while no `permissions` block exists. Saving a rule never changes the starting mode, so once the first rule is written, later sessions start in `default`. If the user wants to keep starting in auto, ask them, and if they agree propose it explicitly: `propose_policy` with `{ "op": "set-mode", "mode": "auto", "scope": "global" }`. It is a loosen, so the user sees and approves exactly that change. Project scope can only lower the mode, so raising it must be global. Headless, a loosen is auto-refused: report the `set-mode` suggestion instead. If the user already chose a mode, don't propose one.
+
 ## Interactive vs. headless
 
 - **Interactive:** follow every step, using `ask_user` to confirm choices.
@@ -24,7 +26,25 @@ If the user is not in auto mode, still proceed — the rules are valid in any mo
 
 ---
 
-## Step 1 — Explore the project
+## Step 1 — Detect the OS and shell dialect
+
+CODA's command rules are **dialect-scoped**: a `Bash(...)` rule only matches when the session's resolved shell routes to the POSIX extractor, and a `PowerShell(...)` rule only matches when it routes to the PowerShell extractor. A bash rule is **inert on Windows PowerShell**, and a PowerShell rule is inert on macOS/Linux. So you MUST author rules for the dialect the user actually runs, or the rules silently match nothing.
+
+Detect the platform first, then pick the dialect:
+
+- Run a quick probe to learn the OS/shell. Prefer a portable check, e.g. `uname -s` (prints `Darwin`/`Linux` on macOS/Linux; fails or is absent on native Windows), or inspect the environment. On Windows, `$PSVersionTable` / `echo $env:OS` confirm PowerShell.
+- Map the result to a dialect:
+  - **macOS (`Darwin`) or Linux → `bash` dialect.** Author `Bash(...)` rules. (This also covers WSL and any POSIX shell — bash/zsh/sh/dash/ksh/ash.)
+  - **Windows PowerShell / pwsh → `pwsh` dialect.** Author `PowerShell(...)` rules (the tags `PowerShell(...)`, `powershell(...)`, and `pwsh(...)` are all equivalent).
+- If the probe is ambiguous, ask the user with `ask_user` which shell they run (`bash`/`zsh` vs `PowerShell`) before proposing any command rules.
+
+State the detected dialect back to the user, e.g. *"You're on macOS, so I'll propose `Bash(...)` rules"* or *"You're on Windows PowerShell, so I'll propose `PowerShell(...)` rules"*, and use **that dialect for every command rule** in the steps below. Everywhere this skill shows `Bash(...)`, substitute `PowerShell(...)` when the user is on Windows.
+
+> Note: file rules (`Read`/`Edit`/`Write`) and MCP rules (`mcp__server`) are **not** dialect-scoped — they apply on every OS unchanged. Only command rules switch between `Bash(...)` and `PowerShell(...)`.
+
+---
+
+## Step 2 — Explore the project
 
 Understand what commands this project legitimately runs so your rules fit reality. Do NOT skip this.
 
@@ -38,7 +58,9 @@ Search in the ~/.coda/coda.db database for bash commands to get a sense of the c
 
 ---
 
-## Step 2 — Choose how permissive the rules should be
+## Step 3 — Choose how permissive the rules should be
+
+> Use the dialect you detected in Step 1 for every command rule below. The examples show the `Bash(...)` (macOS/Linux) form; on Windows author the `PowerShell(...)` equivalents from the palette further down.
 
 Ask the user which posture they want. Use `ask_user`:
 
@@ -47,32 +69,34 @@ Ask the user which posture they want. Use `ask_user`:
 > - **Restrictive** — allow only a short, explicit allowlist; `ask` before anything not on it; deny a broad set of destructive/network commands.
 > - **Balanced** — allow the confirmed dev commands, `ask` for git-writes and network/publish, deny destructive ones.
 
-Then, using what you found in Step 1, propose the concrete rule set and confirm the risky ones with `ask_user` before writing. Typical shapes (adapt to the actual project):
+Then, using what you found in Step 2, propose the concrete rule set and confirm the risky ones with `ask_user` before writing. Typical shapes (adapt to the actual project):
 
-- **Allow** (permissive/balanced): `Bash(pnpm test:*)`, `Bash(pnpm lint:*)`, `Bash(pnpm type-check)`, `Bash(git status)`, `Bash(git log:*)`, `Bash(git diff:*)`.
+- **Allow** (permissive): `Bash(pnpm:*)`, `Bash(git:*)`, `Bash(bunx)`, `Bash(npx)`, `Bash(git:*)`, `Bash(python3:*)`.
 - **Ask** (guardrails on state-changing / outbound actions): `Bash(git push:*)`, `Bash(git commit:*)`, `Bash(npm publish:*)`, `Bash(curl:*)`.
 - **Deny** (destructive / dangerous): `Bash(rm:*)`, `Bash(git reset --hard:*)`, `Bash(chmod:*)` — deny whatever the user does not want the agent doing unattended.
 
 Rule syntax reminders (this is exactly what `propose_policy` writes):
-- `Bash(npm:*)` = any command starting with `npm`; `Bash(git push origin main)` = exact match; `Bash(*)` = any bash command (**too permissive — don't recommend it**, see below); bare `Bash` = the whole tool.
-- File tools take globs: `Read(//etc/passwd)` (double slash = absolute), `Edit(src/**)`, `Write(package.json)`.
+- **Command rules are dialect-scoped (Step 1):** `Bash(...)` matches POSIX shells (macOS/Linux); `PowerShell(...)` (also written `pwsh(...)` / `powershell(...)`) matches Windows PowerShell. Author the tag for the detected OS — the other tag is inert.
+- `Bash(npm:*)` = any command starting with `npm`; `Bash(git push origin main)` = exact match; `Bash(*)` = any bash command (**too permissive — don't recommend it**, see below); bare `Bash` = the whole tool. On Windows the same shapes are `PowerShell(npm:*)`, `PowerShell(Remove-Item -Recurse ...)`, etc.
+- PowerShell command names are **case-insensitive** and cmdlet aliases are normalized — `PowerShell(Invoke-Expression:*)` also matches `iex`, and `-Force` matches `-force`. Bash names stay case-sensitive.
+- File tools take globs (dialect-independent): `Read(//etc/passwd)` (double slash = absolute), `Edit(src/**)`, `Write(package.json)`.
 - MCP: `mcp__filesystem` (whole server) or `mcp__filesystem__read_file` (one tool).
 - Effects: `allow` (no prompt), `ask` (always prompt, even in auto), `deny` (always block).
 
-Precedence is **deny-first**: `deny` > `ask` > `allow` > mode. Nothing overrides a `deny`, and nothing overrides the catastrophic floor (`rm -rf /`, `sudo`, private-key/credential reads, writes to secret files like `.env` / `.secrets`, etc. — never relaxable, so don't bother proposing rules for those). Note that editing `config.json`, `mcp.json`, or `agents.md` is *not* on that floor: it is allowed as an approval-gated authoring write (see Step 5).
+Precedence is **deny-first**: `deny` > `ask` > `allow` > mode. Nothing overrides a `deny`, and nothing overrides the catastrophic floor (`rm -rf /`, `sudo`, private-key/credential reads, writes to secret files like `.env` / `.secrets`, etc. — never relaxable, so don't bother proposing rules for those). Note that editing `config.json`, `mcp.json`, or `agents.md` is *not* on that floor: it is allowed as an approval-gated authoring write (see Step 6).
 
 ### Command-scoped allow rules
 
-IMPORTANT: Do not recommend `Bash(*)` as it won't allow cases that are related to package managers, etc. 
-Bash(*) doesn't allow every bash command, it isn't the most permissive rule possible. 
-Each command is broken down and evaluated independently. 
+IMPORTANT: Do not recommend `Bash(*)` (or `PowerShell(*)`). A token-less wildcard is deliberately **rejected as a floor-relaxer** by the engine: install-class commands (package managers, package runners, interpreter installs) keep asking even with `Bash(*)` present, so it does not actually give the blanket auto-approval users expect — it just weakens their allowlist without buying the convenience. Each sub-command of a compound command (`a && b`) is also evaluated independently, so a broad allow can never rescue a sub-command a floor or deny rule blocks.
 
-Recommendation: **allow one command family at a time** with `Bash(<tool>:*)`. Each such rule auto-allows only that executable and its arguments, so the agent can run the tool freely while everything else still falls back to `ask`/`deny`/mode.
+Recommendation: **allow one command family at a time** with `Bash(<tool>:*)` (or `PowerShell(<tool>:*)` on Windows). Each such rule auto-allows only that executable and its arguments — and, because it names a binary, it *can* relax that command's install-class floor — while everything else still falls back to `ask`/`deny`/mode.
 
 - If a user needs to run **all `pnpm` commands**, the ideal rule is `Bash(pnpm:*)` — not `Bash(*)`.
 - Same idea per tool: `Bash(bun:*)` for all `bun` commands, `Bash(cargo:*)` for all `cargo` commands, and so on.
 
-Build the allow list from the tools the project actually uses (from Step 1). A palette of common command-scoped rules to draw from:
+Build the allow list from the tools the project actually uses (from Step 2). **Pick the palette for the detected OS** (Step 1) — use the `Bash(...)` palette on macOS/Linux, the `PowerShell(...)` palette on Windows. Do not mix dialects.
+
+**macOS / Linux (`bash` dialect):**
 
 ```jsonc
 // ❌ do NOT recommend this:
@@ -107,14 +131,46 @@ Build the allow list from the tools the project actually uses (from Step 1). A p
 "Bash(sqlite3:*)", "Bash(ffmpeg:*)", "Bash(ffprobe:*)", "Bash(open:*)"
 ```
 
+**Windows PowerShell (`pwsh` dialect):** same idea, one command family per rule, but authored with the `PowerShell(...)` tag. Cross-platform tools (git, node, package managers) keep the same executable names; native cmdlets replace the POSIX coreutils. Names are case-insensitive.
+
+```jsonc
+// ❌ do NOT recommend this:
+"PowerShell(*)",
+
+// ✅ Recommended: scope to one command family each.
+// Package managers / runtimes (same executables as POSIX):
+"PowerShell(bun:*)", "PowerShell(bunx:*)", "PowerShell(pnpm:*)",
+"PowerShell(npm:*)", "PowerShell(npx:*)", "PowerShell(node:*)",
+"PowerShell(python:*)", "PowerShell(py:*)", "PowerShell(uv:*)", "PowerShell(uvx:*)",
+// Lint / format / build / type-check / test:
+"PowerShell(biome:*)", "PowerShell(tsc:*)", "PowerShell(vitest:*)",
+"PowerShell(jest:*)", "PowerShell(eslint:*)", "PowerShell(prettier:*)",
+// Build / task runners:
+"PowerShell(dotnet:*)", "PowerShell(cargo:*)", "PowerShell(go:*)", "PowerShell(msbuild:*)",
+// Version control:
+"PowerShell(git:*)", "PowerShell(gh:*)",
+// Read-only file / text inspection (cmdlets + common aliases):
+"PowerShell(Get-Content:*)", "PowerShell(Get-ChildItem:*)", "PowerShell(Select-String:*)",
+"PowerShell(Get-Item:*)", "PowerShell(Test-Path:*)", "PowerShell(Measure-Object:*)",
+"PowerShell(Write-Output:*)", "PowerShell(Write-Host:*)", "PowerShell(Sort-Object:*)",
+"PowerShell(Where-Object:*)", "PowerShell(ForEach-Object:*)",
+// Environment / navigation:
+"PowerShell(Set-Location:*)", "PowerShell(Get-Location:*)",
+"PowerShell(Set-Item:*)", "PowerShell(Get-Command:*)",
+// Filesystem-mutating — riskier, usually `ask`/`deny`, not blanket `allow`:
+"PowerShell(New-Item:*)", "PowerShell(Copy-Item:*)", "PowerShell(Move-Item:*)",
+"PowerShell(Remove-Item:*)", "PowerShell(Rename-Item:*)"
+```
+
 Caveats to relay when proposing these:
 - These are all **fairly permissive** examples; if the user wants this you should add one rule for each command the user has in their history of commands executed.
-- The filesystem-mutating (`rm`, `mv`, `cp`, `chmod`, …) and network (`curl`, `wget`) families change state or reach outbound — prefer `ask` (or `deny` for the destructive ones) over a blanket `allow`, and confirm each with `ask_user` first.
-- You can scope tighter than a whole tool: `Bash(pnpm test:*)` allows only `pnpm test …`, `Bash(git log:*)` only `git log …`. Prefer the narrowest rule that still lets the project's real commands run.
+- The filesystem-mutating families (`rm`/`mv`/`cp`/`chmod` on POSIX; `Remove-Item`/`Move-Item`/`Copy-Item` on PowerShell) and network families (`curl`, `wget`, `Invoke-WebRequest`, `Invoke-RestMethod`) change state or reach outbound — prefer `ask` (or `deny` for the destructive ones) over a blanket `allow`, and confirm each with `ask_user` first.
+- You can scope tighter than a whole tool: `Bash(pnpm test:*)` / `PowerShell(git log:*)` allow only that sub-command. Prefer the narrowest rule that still lets the project's real commands run.
+- **A command rule keyed on a bare name can be bypassed by an absolute path**: a `deny Bash(rm:*)` does *not* block `/bin/rm`, and a `deny Bash(curl:*)` does not block `/usr/bin/curl` (same for `PowerShell(...)`). What guarantees protection against `rm -rf /` and friends is the **catastrophic floor**, not user deny rules. Treat `deny`/`ask` command rules as convenience guardrails, not airtight blocks.
 
 ---
 
-## Step 3 — Choose the target scope: project or global
+## Step 4 — Choose the target scope: project or global
 
 Ask the user with `ask_user`:
 
@@ -128,11 +184,11 @@ Map their choice to the `scope` argument (`"project"` or `"global"`) you pass to
 
 ---
 
-## Step 4 — Apply the rules with `propose_policy`
+## Step 5 — Apply the rules with `propose_policy`
 
 For each rule the user confirmed, call `propose_policy` once:
 
-- Add a rule: `op: "add-rule"`, `rule: "<rule string>"`, `effect: "allow" | "ask" | "deny"`, `scope: "<from Step 3>"`.
+- Add a rule: `op: "add-rule"`, `rule: "<rule string>"`, `effect: "allow" | "ask" | "deny"`, `scope: "<from Step 4>"`.
 - Change the mode (if needed): `op: "set-mode"`, `mode: "read-only" | "default" | "auto"`, `scope`.
 - Remove a stale rule: `op: "remove-rule"` with the same `rule` + `effect`.
 
@@ -145,13 +201,13 @@ Do them in a sensible order (deny rules first, then ask, then allow, then any mo
 
 ---
 
-## Step 5 — Optionally enable the LLM safety-check layer
+## Step 6 — Optionally enable the LLM safety-check layer
 
 Ask the user with `ask_user`:
 
 > "Do you want an **LLM safety check** on commands the agent would otherwise run? When enabled, a classifier model reviews commands and can flag/deny risky ones as an extra layer on top of your rules."
 
-This layer is configured under `permissions.llmSafetyCheck` in `config.json`. `propose_policy` does not cover this block, so **edit `config.json` directly** — the same config file they chose in Step 3 (`<repo>/.coda/config.json` for project, `~/.coda/config.json` for global) — merging the block into the existing `permissions` object. Read the file first (create it if absent), then apply the change with `edit`/`write`.
+This layer is configured under `permissions.llmSafetyCheck` in `config.json`. `propose_policy` does not cover this block, so **edit `config.json` directly** — the same config file they chose in Step 4 (`<repo>/.coda/config.json` for project, `~/.coda/config.json` for global) — merging the block into the existing `permissions` object. Read the file first (create it if absent), then apply the change with `edit`/`write`.
 
 This is a control-plane authoring write, so CODA will show a **mandatory approval prompt** describing the effect before anything is saved. Tell the user to expect and approve it; if they decline, the block is not written. If you cannot get approval (e.g. headless), fall back to giving them the JSON snippet to paste in by hand.
 
@@ -165,10 +221,7 @@ The block to add:
       // Optional: an explicit model list REPLACES the built-in default.
       // Omit this key to use the shipped default classifier models.
       // If you want to use another model, just modify the list. 
-      "models": ["openai/gpt-5.4", "openai/gpt-5.4", "anthropic/claude-sonnet-4-6", "anthropic/claude-haiku-4-5"],
-      // Optional: after this many auto-approvals in an interactive session,
-      // a one-time nudge suggests adding an explicit allow rule. Default: 10.
-      "nudgeThreshold": 10
+      "models": ["openai/gpt-5.4", "openai/gpt-5.4", "anthropic/claude-sonnet-4-6", "anthropic/claude-haiku-4-5"]
     }
   }
 }
@@ -177,12 +230,11 @@ The block to add:
 Notes to give the user:
 - It is **default-off**; an absent block leaves it inert. Set `enabled: true` to turn it on.
 - If `enabled: true` but `models` is an empty list `[]`, the check is inert (a startup warning fires). Omit `models` to use the built-in default, or list at least one model.
-- `nudgeThreshold` must be an integer ≥ 1.
-- If they picked **project** scope in Step 3, this belongs in the project config; if **global**, in `~/.coda/config.json`. Since it rides the global→project cascade, a project block overrides the global one.
+- If they picked **project** scope in Step 4, this belongs in the project config; if **global**, in `~/.coda/config.json`. Since it rides the global→project cascade, a project block overrides the global one.
 
 ---
 
-## Step 6 — Wrap up: tell the user to restart
+## Step 7 — Wrap up: tell the user to restart
 
 After applying rules and (optionally) writing the safety-check block, finish with a short summary of what was set, then clearly instruct the user:
 

package/coda

@@ -1,4 +1,4 @@
 [diffend] Oversized file quarantined before diffing.
 name: package/coda
-size: 131139904 bytes
-sha256: 7a0990aca788c9901f641fc02838edc612afc5e922a8fba81ae154ac43f1df26
+size: 108710184 bytes
+sha256: cb9742b992c992bee91b9447b54238b8a6858709f10d0467ceb53eaa1afdd3e9

package/lib/opentui/parser.worker.js

@@ -18,22 +18,23 @@ var __toESM = (mod, isNodeMode, target) => {
       return cached;
   }
   target = mod != null ? __create(__getProtoOf(mod)) : {};
-  const to = isNodeMode || !mod || !mod.__esModule ? __defProp(target, "default", { value: mod, enumerable: true }) : target;
-  for (let key of __getOwnPropNames(mod))
-    if (!__hasOwnProp.call(to, key))
-      __defProp(to, key, {
-        get: __accessProp.bind(mod, key),
-        enumerable: true
-      });
+  const to = isNodeMode || !mod || !mod.__esModule || !__hasOwnProp.call(mod, "default") ? __defProp(target, "default", { value: mod, enumerable: true }) : target;
+  if (mod && typeof mod === "object" || typeof mod === "function") {
+    for (let key of __getOwnPropNames(mod))
+      if (!__hasOwnProp.call(to, key))
+        __defProp(to, key, {
+          get: __accessProp.bind(mod, key),
+          enumerable: true
+        });
+  }
   if (canCache)
     cache.set(mod, to);
   return to;
 };
 var __commonJS = (cb, mod) => () => (mod || cb((mod = { exports: {} }).exports, mod), mod.exports);
-var __require = import.meta.require;
 
 // ../../node_modules/.pnpm/web-tree-sitter@0.25.10/node_modules/web-tree-sitter/tree-sitter.wasm
-var require_tree_sitter = __commonJS((exports, module2) => {
+var require_tree_sitter = __commonJS(function(exports, module2) {
   module2.exports = Bun.fileURLToPath(new URL("./tree-sitter-3jzf13jk.wasm", import.meta.url));
 });
 
@@ -1576,7 +1577,7 @@ var Module2 = (() => {
           throw new Error(response.status + " : " + response.url);
         }, "readAsync");
       }
-    } else {}
+    }
     var out = Module["print"] || console.log.bind(console);
     var err = Module["printErr"] || console.error.bind(console);
     Object.assign(Module, moduleOverrides);
@@ -3362,8 +3363,8 @@ class DownloadUtils {
     return "";
   }
 }
-function isBunfsPath(path22) {
-  return path22.includes("$bunfs") || /^B:[\\/]~BUN/i.test(path22);
+function isBunfsPath(path2) {
+  return path2.includes("$bunfs") || /^B:[\\/]~BUN/i.test(path2);
 }
 function getBunfsRootPath() {
   return process.platform === "win32" ? "B:\\~BUN\\root" : "/$bunfs/root";
@@ -3463,8 +3464,8 @@ var stripANSI = bun?.stripANSI ?? stripAnsi;
 var writeFile2 = bun?.write ?? writeFilePortable;
 async function resolveBundledFilePath(loadBundledFile, fallbackPath, metaUrl) {
   if (!bun) {
-    const path22 = typeof fallbackPath === "function" ? fallbackPath() : fallbackPath;
-    return fileURLToPath(path22 instanceof URL ? path22 : new URL(path22, metaUrl));
+    const path2 = typeof fallbackPath === "function" ? fallbackPath() : fallbackPath;
+    return fileURLToPath(path2 instanceof URL ? path2 : new URL(path2, metaUrl));
   }
   const loadedPath = (await loadBundledFile()).default;
   if (loadedPath.startsWith("file:")) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@globant/coda-linux-arm64",
-  "version": "1.3.0",
+  "version": "1.5.0",
   "description": "Coda CLI native binary (linux-arm64)",
   "os": [
     "linux"