Repository navigation
fix: [SDK-5479] run checkpoint sends inside the sandbox and escalate one flush per skill - #65
Conversation
cbdfd9a to
3f7e1e4
Compare
kalley
left a comment
kalley
left a comment
There was a problem hiding this comment.
The rules read the same across the three skills and both contracts, and the exit-3 claims match onesignal_api.py and resolve_sdk_version.py. One non-blocking note inline.
| the event in `.onesignal/pending.jsonl`, and exits 0. In a sandbox that output is the | ||
| expected result, not an error: do not re-run the call with escalation, and do not stop | ||
| to report it. | ||
| - **Escalate the closing `flush` (Step 8) once.** One approval sends every held event. |
There was a problem hiding this comment.
A run that stops after Step 2 never gets to this flush, for example after a rejected diff, or a terminal failure in credentials. In a sandbox, that run's fail row then stays in pending.jsonl until a later run flushes it. Those are the rows that the "record a failure the moment you are blocked" rule is there to keep. Should a stop also escalate one flush before it ends the turn? Doesn't block.
abdulraqeeb33
left a comment
abdulraqeeb33
left a comment
There was a problem hiding this comment.
Looks good. checkpoint.sh keeps every held event until the closing flush, and the escalate-after-exit-3 rule matches both helpers. Nothing to add beyond Kalley's note about runs that stop before the closing flush.
…one flush per skill A sandboxed host such as Codex approves one command at a time. The skill text told the agent to request network approval once before Step 0, and no host has that mechanism, so an agent escalated every checkpoint.sh call and the user answered one prompt per milestone. The skills now run every milestone call inside the sandbox, where the script holds a blocked event and exits 0, and escalate only the closing flush of each skill. The version resolver and the API probes escalate only after the sandbox blocked them once. Safety contract 15 and the telemetry contract state the same rule, and the README Codex section names the prompts that remain.
3f7e1e4 to
4b3258d
Compare
One Line Summary
In a sandboxed runtime (i.e. Codex in default mode) the skills now send a flush of telemetry milestones so as to cut down on the number of network approval prompts asked of the user.
Motivation
In testing (specifically Codex in default mode), users noticed that plugin asks for permission for everything; which can be highly disruptive. Codex's default
Automode runs workspace commands without a prompt and asks before each command that needs the network. These approvals added up during the time of the run.Now, the plugin will hold multiple telemetry checkpoints and send them once at the end of the run. This should cut down of number of user request prompts for Codex users significantly.
Ticket: SDK-5479, sub-issue of SDK-5444.