@coinbase/coinbase-cli 0.0.7 → 0.0.8

package/dist/version.txt

@@ -1 +1 @@
-0.0.7
+0.0.8

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@coinbase/coinbase-cli",
-  "version": "0.0.7",
+  "version": "0.0.8",
   "description": "Coinbase for agents — CLI and MCP server for trading, wallets, payments, and onchain across the Coinbase platform",
   "type": "module",
   "bin": {
@@ -8,8 +8,10 @@
   },
   "scripts": {
     "build": "BUILD=external node scripts/embed-spec.mjs",
-    "gen:types": "BUNDLE_SKIP=1 BUILD=external node scripts/embed-spec.mjs && node scripts/gen-types.mjs specs/cli/coinbase-cli.yaml '' > generated/cli/types.ts && node scripts/gen-types.mjs dist/spec.json '' RetailBrokerageApi_ > generated/brokerage/types.ts && node scripts/gen-client.mjs > generated/brokerage/client.ts && node scripts/gen-surface.mjs specs/cli/coinbase-cli.yaml > generated/cli/surface.ts",
+    "gen:spec": "BUILD=external node scripts/resolve-agent-spec.mjs",
+    "gen:types": "pnpm run gen:spec && BUNDLE_SKIP=1 BUILD=external node scripts/embed-spec.mjs && node scripts/gen-types.mjs dist/agent-api.yaml '' > generated/cli/types.ts && node scripts/gen-types.mjs dist/spec.json '' RetailBrokerageApi_ > generated/brokerage/types.ts && node scripts/gen-client.mjs > generated/brokerage/client.ts && node scripts/gen-surface.mjs dist/agent-api.yaml > generated/cli/surface.ts",
     "gen:test": "node scripts/gen-mapping-tests.mjs",
+    "gen:check": "pnpm run gen:spec && node scripts/check-contract.mjs",
     "typecheck": "tsc --noEmit",
     "test": "node --experimental-strip-types --no-warnings --test 'src/**/*.test.ts'",
     "test:keyring": "node --experimental-strip-types --no-warnings --test src/lib/keyring/keyring.integration-test.ts",

package/skills/coinbase-trading/SKILL.md

@@ -68,12 +68,17 @@ Prefer native order types — they are durable and server-side. Only use a `--un
 ```sh
 coinbase orders list status==OPEN
 coinbase orders get <order_id>
+coinbase orders edit-preview order_id=<order_id> limit_price=50000
 coinbase orders cancel order_ids:='["id-1","id-2"]'
 coinbase orders edit <order_id> limit_price=50000
 coinbase orders fills order_id==<order_id>
-coinbase orders close_position product_id=BTC-USD
+coinbase orders close-position product_id=BTC-USD
 ```
 
+`orders edit-preview` reprices an open order without editing it — distinct from
+`orders preview`, which prices an order you have not placed yet. Supply at least
+one of `base_size` or `limit_price`.
+
 ## Portfolio scope
 
 CDP API keys derive portfolio scope from the key itself — no `retail_portfolio_id` needed in the body. To trade in a different portfolio, switch envs (`-e live-trading`); see `coinbase-portfolios`.

package/skills/coinbase-x402/SKILL.md

@@ -57,6 +57,29 @@ The header names are not interchangeable. Never send `X-PAYMENT` to a v2 resourc
 
 If the resource rejects the header, first verify that the challenge's `x402Version`, the `x402_version` passed to `pay`, and the HTTP header name agree. Do not create another payment merely to try the other header name.
 
+## Sign-In With X (SIWX)
+
+When a v2 challenge includes `extensions["sign-in-with-x"]`, a wallet that has already paid for the resource may use SIWX instead of creating another payment. SIWX is a separate HTTP authentication flow: never add it to `x402 pay`.
+
+`coinbase` cannot sign SIWX messages and `x402 fetch` cannot attach custom headers. Use the manual `x402 pay` flow only when the caller has a compatible external wallet signer and can make the resource request itself. Otherwise, omit `SIGN-IN-WITH-X` and pay normally.
+
+Do not manually serialize or sign the extension JSON. Select a `supportedChains` entry compatible with the wallet, then use an x402 SIWX client implementation to:
+
+1. Merge `extension.info` with the selected `chainId` and `type`.
+2. Build the required CAIP-122 message, including the signing wallet address.
+3. Sign that message with the matching wallet.
+4. Emit a proof containing the copied `info` fields, `chainId`, `type`, `address`, and `signature`.
+5. Base64-encode the proof JSON for `SIGN-IN-WITH-X`.
+
+Use a CAIP-122-compatible SIWX client or wallet SDK to construct and sign the proof.
+
+Reject redirects that leave the original catalog URL's origin. Only sign when `extension.info.domain` matches the final URL hostname and `extension.info.uri` exactly matches the final response URL. Preserve every challenge field unchanged. Send the SIWX header on the resource request, with the version-matched x402 payment header when payment is still required:
+
+```http
+PAYMENT-SIGNATURE: <payment_header>
+SIGN-IN-WITH-X: <base64-encoded SIWX proof>
+```
+
 ## Retry safety
 
 Use the smallest `amount` and `max_amount` that satisfy the requirement. Reuse the returned `idempotency_key` only when retrying the same logical payment after an outcome-unknown failure. Starting a retry without it can create another hold.