@tinycloud/cli 1.3.0-beta.52 → 1.3.0-beta.53

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tinycloud/cli",
-  "version": "1.3.0-beta.52",
+  "version": "1.3.0-beta.53",
   "description": "TinyCloud CLI - manage data, delegations, and nodes from the terminal",
   "author": "TinyCloud, Inc.",
   "license": "EGPL",

package/skills/tc-cli/AUTH.md

@@ -128,6 +128,8 @@ Login covers one space. Request further spaces on the logged-in profile:
 
 `auth request --preset apps-agent [--app APP_ID]...` is a named request for an agent that picks up the user's tiny apps. By default it is read-only: `tinycloud.kv` get, list and `tinycloud.sql` read on the `applications` space, up to 7 days. `--app` (repeatable, at most 5) narrows every entry to `APP_ID/`. `--write` (needs `--app`, never for the whole space) adds `tinycloud.kv` put on each app's `knowledge/` and `prefs/` folders only, and `tinycloud.sql` write, for those apps; every other file under `APP_ID/` stays read-only, including the code and the stored `APP_ID/app/manifest.json` and `APP_ID/app/install.json` (the root-level `APP_ID/manifest.json` and `APP_ID/install.json` are refused too). The node lets `sql/write` run CREATE, ALTER and DROP TABLE (TC-1581 is the node-side fix), so the request says that the agent can also change or delete those apps' tables. Neither variant carries KV delete, SQL admin or schema, any other service or space, or secrets. The scope is printed in plain words to stderr before any approval link or artifact. `auth grant` prints a scope for every request it signs, built from the request file as it will be signed: the preset wording only when the permissions, the owner's own `applications` space and the 7-day lifetime all match; otherwise one line per entry (service, space, path, actions in words; an unknown service or action is printed raw and marked "unrecognised"; delegation abilities in plain words such as "can give other people or agents access on your behalf") and the requested lifetime. The request file is resolved once, the way the signer reads it (an entry with no `space` is in your `applications` space and is described as that; an empty space is refused; entries with the same service, space and path are merged), and that one list is printed, gated and signed. Each entry is printed once. A request that carries the `tinycloud.vault` shorthand (the signer turns it into KV access on `vault/` for the vault actions you listed, which the printed list would not show), a service the signer cannot sign, or more than one space is refused with exit 2 before anything is printed or signed. The request's `sessionDid` and `requestedExpiry` are checked first. Text from the request is escaped, in error messages too (on a terminal every error message and hint is escaped, and JSON output writes control, bidi, zero-width and separator characters as `\uXXXX` escapes, which parse to the same text, so a redirected stdout with a terminal stderr is safe too), and refusal messages show at most 5 items of 80 characters each. When the request touches an `applications` space and holds any entry the preset could never grant, those entries are marked `!` and listed first under "MORE than the apps-agent preset" and signing needs `--yes` or an interactive confirmation; without a terminal it exits 2 and signs nothing. The preset replaces `--cap`, `--permission`, `--manifest` and `--expiry` (combining them is a usage error), and `--device` is refused because device approval cannot grant SQL. An empty path in `--cap` (`tinycloud.kv:applications::get,list`) covers the whole service in that space; a path ending in `/` covers the prefix. The agent's key can pass on access inside its own grant, so a grant is as private as the agent's profile. The owner revokes a grant made through the request, grant, import flow with `tinycloud delegation revoke CID`. A profile whose first grant was revoked or expired has a dead session; import the new grant into a new profile. See the `tc-cli` skill, "Pick up a user's apps".
 
+The owner approves each agent grant in OpenKey. `--yes` does not skip that screen. Before writing the grant file, the owner CLI checks the approval's owner, space and scope, and the grant lasts as long as the approval allows. An approval that unchecks any requested ability is refused with `OPENKEY_APPROVAL_NARROWER`, and nothing is stored. Without a browser, the CLI prints the approval link and waits for the browser flow to finish. The grant JSON reports `"prompted": true`, because the owner approved it on that screen.
+
 ## Imported delegations and their request bindings
 
 Delegations stored in a profile's `additional-delegations.json` replay only into that profile's restored session. Compact-UCAN and signed-login (CACAO) grants must carry a verifiable proof and a valid `authorityRequest` binding whose `requested` capabilities contain all of their signed authority. The CLI, `tinycloud secrets get`, and MCP tools all apply this rule; expired records and cross-user compact grants with a verified CID, signature, and signed audience matching the stored transport audience are skipped silently, while refused replay candidates produce fixed-code `STORED_GRANT_SKIPPED` warnings. A stored record whose `delegationHeader` is anything but a single string `Authorization` installs nothing.

package/skills/tc-cli/SKILL.md

@@ -74,11 +74,12 @@ Ask for the narrowest grant that does the job. The default is read-only, and one
 
 - `--preset apps-agent` is **read-only**: KV get and list, SQL read, on the `applications` space, up to 7 days. That is enough to pick up where the user left off by reading `knowledge/*` and querying the data. The node refuses a KV put or a SQL write under it.
 - `--app APP_ID` limits it to `APP_ID/` and is the recommended default. Repeat `--app` (up to 5) for a task that spans apps. Leave it off only to read every installed app; the command says so before the owner approves.
-- **Write access only when the owner asks to change an installed app's data** (for example, log a meal). The agent requests it from its own profile with one command: `"$TC" --profile agent auth request --preset apps-agent --app APP_ID --write --emit req.json`. The owner approves it once, then the agent imports the grant as above. `--write` needs `--app`, and the grant lasts up to 7 days.
+- **Write access only when the owner asks to change an installed app's data** (for example, log a meal). The agent requests it from its own profile with one command: `"$TC" --profile agent auth request --preset apps-agent --app APP_ID --write --emit req.json`. The owner approves it in OpenKey, then the agent imports the grant as above. `--write` needs `--app`. The grant lasts as long as the owner's approval allows, up to 7 days.
 - With `--write`, the agent can add and change that app's data: it writes files under `APP_ID/knowledge/` and `APP_ID/prefs/` and changes its tables, which can include changing or dropping a table, so confirm with the owner before structural changes. It cannot change the app's code, its manifest or its install record, and every other file under `APP_ID/` stays read-only. It cannot touch other apps, other spaces or secrets.
 - Before you request write access, confirm with the owner. The grant covers one named app: never ask for the whole space, and never a write without `--app`.
 - The preset cannot be combined with `--cap`, `--permission`, `--manifest` or `--expiry`, and device approval cannot grant it (SQL needs browser or `--paste`). The owner ends the grant with `tinycloud delegation revoke GRANT_CID`; the CID is in the `auth grant` output. Within its own grant the agent's key could pass the same access on to someone else, so keep the key and the grant file private.
 - The owner's `auth grant` prints every permission it is about to sign, built from the request file. A request that holds anything the preset could never grant (another service or space, delete, schema, delegation, a write without a named app, a KV put outside `APP_ID/knowledge/` and `APP_ID/prefs/`) is listed first, marked `!`, under "MORE than the apps-agent preset" and is signed only after `--yes` or an interactive confirmation; without a terminal it exits 2 and signs nothing. If the text shows a different lifetime or scope than the one you asked for, the request file was edited.
+- Every `auth grant` on an OpenKey owner profile goes to OpenKey approval, including a plain apps-agent request with no extra entries. `--yes` never skips OpenKey approval; it skips only the extras list confirmation.
 - **A revoked or expired grant cannot be replaced in the same profile.** A delegate profile's session is its first imported grant; a later `auth import` succeeds but invocations keep using the first one, so `knowledge list` answers `AUTH_REQUIRED`. Create a new profile (`profile create`), make a new request from it and import the new grant there.
 
 Then: