The fix-apply API lets you attach a proposed shell command to a ticket, verify it against a configured allowlist, execute it, re-run the associated test to confirm the fix worked, and resolve the ticket automatically on success. Every command execution — whether allowed or denied — is written to an audit log. The fix-apply layer is disabled by default; you must explicitly allowlist commands inDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/onenot8/issueLoop/llms.txt
Use this file to discover all available pages before exploring further.
config/permission.yaml before any command can be run.
propose_fix
Stores a shell command in the ticket’sproposed_fix field. This does not execute anything — it is a staging step before calling apply_fix.
UUID of the ticket to attach the proposed fix to.
Shell command string to store. This value is checked against the permission allowlist when
apply_fix is called.proposed_fix set, or None if the ticket was not found.
apply_fix
Checks the ticket’sproposed_fix against the permission allowlist, runs it if allowed, re-runs the ticket’s test, and advances the ticket status based on the outcome.
UUID of the ticket to fix. Must have a
proposed_fix set (call propose_fix first).Maximum number of fix attempts before the ticket is automatically escalated to
needs_human.Timeout in seconds for the shell command execution.
One of:
"resolved"— command ran, test passed, ticket is nowdone"retry"— command ran, test failed, attempts incremented, ticket reset topending"escalated"— command ran, test failed,max_retriesexhausted, ticket is nowneeds_human"denied"— command was not in the allowlist, ticket state unchanged
UUID of the ticket that was processed.
The attempt count at the time of the result (present for
resolved, retry, and escalated).Present only when
status is "denied" — describes which allowlist rule blocked the command.apply_fix requires propose_fix to have been called first. If ticket.proposed_fix is empty, a ValueError is raised. When the ticket has a test_id, the outcome is determined by re-running that specific test. When no test_id is set, the fix command’s own exit code is used as the pass/fail signal.check_permission
ReturnsTrue if the command is allowlisted for the given repository, False otherwise. This is a read-only check — it writes an audit entry but does not execute the command.
Shell command string to check.
Repository name to check against. The allowlist merges global rules with per-repo rules from
config/permission.yaml, and also auto-allows any command listed in the repo’s test_manifest.json.True or False. Does not raise on denial — call run_guarded from the permissions module directly if you want an exception on denial.
get_permission_audit_log
Returns audit log entries recorded by the permission system. Every call tocheck_permission or apply_fix writes an entry — both allowed and denied outcomes are logged.
Optional repository filter.
None returns entries across all repos.Maximum number of entries to return. Returns the most recent
limit entries.ISO 8601 UTC timestamp of the permission check.
One of
allowed_exact, allowed_pattern, or denied.Repository the command was checked for.
The command string that was evaluated.
For
allowed_pattern events, the regex pattern that matched. Empty for other events.