--- title: "Edit an approval or allow repeated calls" description: "Edit an approval or allow repeated calls for people running and reviewing agents." canonical_url: "https://docs.oz0.ai/agents/approvals/edits-and-repeat-calls" --- # Edit an approval or allow repeated calls > Edit an approval or allow repeated calls for people running and reviewing agents. For: people running and reviewing agents. ## Approve with edits A person who may decide and holds the content permission can approve the call with other arguments instead of denying it: **Edit and approve** on the card, Slack's modal in a [chat thread](https://docs.oz0.ai/build/apps/chat-channels), or the CLI: ```bash [Terminal] oz0 approval args job-bb270cf1-... a-3d3774fd06c3 --json | jq .arguments > call.json # change what you need oz0 approval approve job-bb270cf1-... a-3d3774fd06c3 --edit-file call.json ``` The edit is a new proposal, checked before the job hears of it: it must fit the function's input schema, the tenant's tool policy (with its conditions) must not refuse it, and it must not need another approval than the one being decided. The job checks it again, and the call is made with exactly the edited arguments. The agent reads a note that names the fields you changed (`user:ana edited amount, to before approving this call; it was made with their values`), never their old values. While the job runs, its page's live stream says approved with edits and names the changed fields, as the chat drawer marks the request. The audit entry `run.approval.decide` records `edited`, both digests and the changed fields; the values are in its private part, for readers with the content permission. Integers past 2^53. A call's arguments keep an integer's exact digits, in `args_sha256` and in the job's check, and a card's preview shows the number as the call holds it. The whole arguments, which a cut preview's **Show all arguments** and `oz0 approval args` fetch, carry numbers as doubles, which round from 2^53 up, so they show such an integer as a string of its digits. An edit carries numbers the same way, so an edit holding a whole number of 2^53 (9,007,199,254,740,992) or more is refused with `give it as a string`. An edit carries such an integer only as a string, where the function's input schema takes one; where it does not, approve the call as it stands or deny it. ### The field set The form draws the standard field set from the input schema: text, number, choice, multi-choice, date (with or without a time) and toggle, in the order the schema's `x-oz0-order` lists, then the required arguments, then by name. An enum is a choice (a nullable one offers leaving it empty); an enum of values a form cannot offer is no field, never a free text. Before anything is sent, you confirm a diff of what changes (a diff is shown beside the fields; it is not a field). An argument the set does not map is edited as JSON on the card. The same set draws [typed questions](https://docs.oz0.ai/agents/asking-people#typed-questions) and the chat picker's form (which keeps the schema's written order when it has no `x-oz0-order`), and the console, the edge and the Slack and Teams plugins run one set of test cases for it. ### Edit forms in chat threads
Chat Edit and approve
Slack A modal with the call's first 20 fields and their values. See how Slack preserves values .
Microsoft Teams The card's inputs: a multi-choice sent by its options' positions (an option may hold a comma), a date and time as a date input and a time input in UTC, and Leave empty for an optional choice or date.
Discord Open in OZ : Discord answers a form within three seconds from the interaction alone, so it cannot carry a call's fields.
### Slack field values Slack opens a modal with the call's first 20 fields and their values. An optional choice offers **Leave empty**, and an optional date or date and time a **Leave … empty** box under its picker: either leaves the argument out. A field left as the form showed it stays exactly as the call had it: a date and time (in UTC, to the minute), a date cut from a date and time, a text with spaces around it or longer than the 3,000 characters a Slack input holds; an emptied date or choice picker still means unchanged. What a chat's form sends is read exactly before the edit is checked against the input schema and the tool policy: a number is plain digits (`1500` or `12.5`, never `1,500` or `12abc`, and nothing that is not finite), a whole-number field takes no fraction, and the field's minimum, maximum, maximum length, required flag and date format (`2026-10-21`, or `2026-10-21T09:30:00Z` with its offset) hold, or the form says what does not fit. The same holds for a typed question's answer from a chat. Arguments a chat's form does not show (those the set does not map, those the schema does not describe, and the fields past the first 20) keep their values, and the form says which; edit them in OZ. Every approval posted to a chat has **Open in OZ**, a link button to the job's page in the console (under the server's `--public-url`; a link carries no token, and the console asks you to sign in). A tool whose calls must be approved exactly as written says `approval: {edit: false}`. ## Allow the same call again When an agent will make the same call several times in one job, the person may approve it with **Allow the same call in this job for** 15 minutes, an hour or eight hours (`oz0 approval approve ... --allow-for 1h`, at most seven days). Later calls of the same agent and function in the same job with exactly the same arguments then run without asking until it runs out. A call that differs asks again, and its card names the arguments that changed. So does the same call after the tool's plugin was upgraded or the tenant's tool policy changed: the person allowed it under that version and that policy, as with any approval. It never reaches another job, a child job or the next turn of a conversation, and never a call that asks for a typed confirmation. It covers a call whoever asked about it: the tool's `requires_approval`, a rule of the tenant's policy or its condition, the taint, the origin check, a sequence rule, or a harness tool under the agent's `harness.requires_approval`. It also covers a [command rule](https://docs.oz0.ai/govern/command-rules)'s Ask, as **Allow the same command in this job for**: later asks of the same agent's shell tool with the same call run without asking: the same command, its argument list, its working directory, its environment and every other field of the call, all but the harness's description and title of it, which it writes anew each time. A call that differs in any of them asks again, and its card says the command changed: an environment the person did not see can change what the same command runs. A call that names no command (no `command` or `cmd`) is never allowed again this way, so a yes to it covers nothing else. The command rules still decide each command first, so a Refuse still refuses it. It never covers another hook's escalation, such as the intent check's, which asks every time, and the hooks still run before every call it lets through. A command a command rule asked about can also be allowed or refused for good from its card: see [Allowlist a command from its card](https://docs.oz0.ai/govern/command-rules/allow-from-card#allowlist-a-command-from-its-card). After you approve a call the tenant's tool policy asked about, the card and the CLI suggest the narrowest rule that would have allowed exactly that call: the one function, the agent, and every argument pinned to its value. It changes nothing by itself; copy it, or the `oz0 policy allow ... --shadow` command that adds it in shadow mode, review it and add it to the [tool policy](https://docs.oz0.ai/govern/tool-policy) if you want such calls to run. **Approve** and **Deny** are a person's own answer to one call; the policy's words for what a rule does are Allow, Ask and Refuse. ## Sitemap See the full [sitemap](https://docs.oz0.ai/sitemap.md) for all pages.