@withone/cli 2.3.2 → 2.5.0

package/README.md

@@ -185,7 +185,7 @@ Opens your browser, you authorize, done. The CLI polls until the connection is l
 
 ### `one list`
 
-List your active connections with their status, connection keys, and what your access config lets you run on each.
+List your active connections with their status, connection keys, and the access this key has on each.
 
 ```bash
 one list
@@ -199,15 +199,15 @@ one list
 
 You need the connection key (rightmost column) when executing actions.
 
-**Access reporting.** Every connection carries an `access` field describing what the current [access control](#one-config) config permits — so an agent knows its reach up front instead of discovering it as a failure mid-workflow. Three policies:
+**Access reporting.** Every connection carries an `access` field: what this key may run there. The CLI reads it from One (`GET /v1/access/me`, the access chosen on the consent page or later in the dashboard) and narrows it by any limits you set with [`one config`](#one-config) — the server's answer is the ceiling, local settings can only lower it.
 
-| Policy | Means | Shown when |
-|--------|-------|-----------|
-| `{"policy": "full"}` | Every action on the connection | Default (admin, no action allowlist) |
-| `{"policy": "methods", "methods": ["GET"]}` | Only actions with those HTTP methods | Permission level is `read` or `write` |
-| `{"policy": "actions", "actions": [{"actionId": "...", "title": "...", "method": "..."}]}` | Only these specific actions | An action allowlist is configured |
+| Policy | Means | `level` |
+|--------|-------|---------|
+| `{"policy": "full"}` | Every action on the connection | `full` (Full access) |
+| `{"policy": "methods", "methods": ["GET"]}` | Only actions with those methods | `read-only`, `read-write` (GET, POST, PUT, PATCH), or `custom` |
+| `{"policy": "actions", "actions": [{"actionId": "...", "title": "...", "method": "..."}]}` | Only these specific actions | `custom`, or `none` when empty |
 
-An action allowlist wins over the permission level (and is then method-filtered by it). When the policy is `actions`, those actions are exactly what may run — `actions load <actionId>` reads their docs, no find needed.
+A connection the key does not reach is not listed. When the policy is `actions`, those actions are exactly what may run — `actions load <actionId>` reads their docs, no find needed.
 
 ```jsonc
 // one --agent list
@@ -219,14 +219,14 @@ An action allowlist wins over the permission level (and is then method-filtered
       "platform": "gmail",
       "state": "operational",
       "key": "live::gmail::default::abc123",
-      "access": { "policy": "methods", "methods": ["GET"] }
+      "access": { "policy": "methods", "methods": ["GET"], "level": "read-only" }
     }
   ],
-  "accessHint": "Permission level \"read\": only GET actions will execute."
+  "accessSource": "server"
 }
 ```
 
-`knowledgeOnly: true` appears when knowledge-only mode is on (execution disabled), and `unresolvedActionIds` lists any allowlisted action ids that could not be looked up. In human output, an `Access` column and a summary note appear only when access is actually scoped.
+`accessSource` is `"server"` when One reported the key's access and `"local"` when it could not (an older API); then `access` shows only the CLI's own settings, the human table labels the column "Access (CLI settings only)", and `accessHint` says One may allow less. `knowledgeOnly: true` appears when knowledge-only mode is on (execution disabled), and `unresolvedActionIds` lists action ids that could not be looked up.
 
 This mirrors the `access` field on the One MCP server's `list_one_integrations` tool, so both surfaces report access the same way.
 
@@ -498,6 +498,28 @@ one relay deliveries --endpoint-id <id>    # Check delivery status
 
 Start with `one relay platforms` to discover which platforms support relay at all, then drill into `event-types <platform>` for the specific events. Run `one guide relay` for the full reference including `--metadata` requirements per platform.
 
+### `one skills`
+
+Optional skills for your coding agent, installed on request. The One skill itself still comes from `one init` (and `one config skills sync|status`); these commands never touch it.
+
+```bash
+one skills list                          # the One skill and each optional skill, with where it is installed
+one skills add connect                   # the One Connect skill, into this project
+one skills add connect --global          # ...or for every project on this machine
+one skills add connect --agents claude-code,windsurf   # link exactly these agents
+one skills update [connect]              # re-copy after upgrading @withone/connect
+one skills remove connect                # remove it and the agent folders that point at it
+```
+
+What `one skills add connect` does:
+
+1. **Finds the skill** in the `@withone/connect` package your project installed (`node_modules/@withone/connect/skills/one-connect`), so your agent reads the docs for the exact SDK version your code calls. If the package isn't installed yet, it downloads the latest published package from npm and checks it against the registry's integrity hash first.
+2. **Installs it** into `.agents/skills/one-connect` (read by Codex, Cursor, Amp and OpenCode) and links `.claude/skills/one-connect` for Claude Code. Windsurf, Kiro, Goose and Roo get a link when the project already has their folder (`.windsurf`, `.kiro`, `.goose`, `.roo`). Where links aren't allowed (Windows without developer mode), it uses a junction, then a copy.
+3. **Stamps** the install with the package version in `.one-skill.json`.
+4. **Keeps it fresh**: any `one` command run in the project re-copies the skill when the installed `@withone/connect` version changes. Local files only; no network.
+
+Commit `.agents/skills/one-connect` and the agent links so your team's agents share the skill. Agent mode (`--agent`) returns JSON for every subcommand.
+
 ### `one guide [topic]`
 
 Get the full CLI usage guide, designed for AI agents that only have the binary (no MCP, no IDE skills).

package/dist/{chunk-6FA7KUNQ.js → chunk-MRQ47KSZ.js}

@@ -104,6 +104,20 @@ var OneApi = class {
     if (!text) return {};
     return JSON.parse(text);
   }
+  /**
+   * The calling key's own access, as One enforces it: `GET /v1/access/me`.
+   * Resolves `null` for a key with no restrictions. Throws `ApiError` when the
+   * API does not answer it (for example an older backend without the route).
+   */
+  async getOwnAccess() {
+    const body = await this.request("/access/me");
+    if (body === null) return null;
+    if (typeof body !== "object" || !("rules" in body || "methods" in body)) {
+      throw new ApiError(502, "Unexpected answer from /access/me");
+    }
+    const doc = body;
+    return { methods: doc.methods ?? null, rules: doc.rules ?? null };
+  }
   async whoami() {
     return this.request("/users/whoami");
   }
@@ -2285,7 +2299,7 @@ async function executeSubflowStep(step, context, api, permissions, allowedAction
   if (flowStack.includes(resolvedKey)) {
     throw new Error(`Circular flow detected: ${[...flowStack, resolvedKey].join(" \u2192 ")}`);
   }
-  const { loadFlowWithMeta: loadFlowWithMeta2 } = await import("./flow-runner-SFECNAO2.js");
+  const { loadFlowWithMeta: loadFlowWithMeta2 } = await import("./flow-runner-4A5ANCTT.js");
   const { flow: subFlow, rootDir: subRootDir } = loadFlowWithMeta2(resolvedKey);
   const subContext = await executeFlow(
     subFlow,

package/dist/{flow-runner-SFECNAO2.js → flow-runner-4A5ANCTT.js}

@@ -12,7 +12,7 @@ import {
   stripStepsAlias,
   summarizeFlowInputs,
   walkSteps
-} from "./chunk-6FA7KUNQ.js";
+} from "./chunk-MRQ47KSZ.js";
 import "./chunk-44CV5IMX.js";
 import "./chunk-HTXZZQ6U.js";
 export {