Agent tools CLI

Coding agents call 143-tools from inside the sandbox to query connected integrations without handling provider credentials directly. The available commands depend on which integrations are configured for the session, so 143-tools --help is the source of truth at runtime.

Use this page as a lookup table. For task flows, start with the guide for the integration or preview workflow you are configuring.

CLI contract

Agent-facing commands use a hierarchical shape:

143-tools <namespace> <action> [--flag value ...]
143-tools <namespace> --help
143-tools <namespace> <action> --help
143-tools --help

Results are printed to stdout, usually as JSON. Flags map directly to the tool input schema. Array flags use comma-separated values, for example --states triage,in_progress. Boolean flags accept true or false.

Flat command names such as sentry_list_errors, linear_get_task, log_query, and create_pr are no longer supported. Error messages include the new command shape and the help command the agent should run next.

Use jq when scanning result sets:

143-tools linear list_tasks --team ENG --limit 25 | jq '.[].identifier'

Namespaces

Only configured namespaces appear in 143-tools --help.

Error tracking

These commands are exposed for configured error trackers such as Sentry. The namespace uses the provider name.

sentry list_errors

List unresolved errors with severity, occurrence count, and affected-user summaries.

Common use: start a production bug investigation with high-impact unresolved errors.

143-tools sentry list_errors --severity critical --limit 20

sentry get_error

Get full details for one error, including stack trace, tags, and error type.

Common use: inspect the stack and tags before searching the codebase.

143-tools sentry get_error --error_id 12345

sentry get_error_trend

Get occurrence trend data over a time window.

Common use: decide whether a suspected fix should be urgent because the error is spiking.

143-tools sentry get_error_trend --error_id 12345 --period 24h

sentry find_related_errors

Find errors that likely share a root cause, such as a matching stack prefix or culprit.

Common use: avoid fixing one symptom while missing duplicate production failures.

143-tools sentry find_related_errors --error_id 12345

Tasks

These commands are exposed for configured task managers such as Linear. The namespace uses the provider name.

linear list_tasks

List tasks matching filters with state, priority, and assignee summaries.

Common use: find the highest-priority engineering work related to the current repo.

143-tools linear list_tasks --team ENG --priority urgent --limit 25

linear get_task

Get full task details, including description, comments, and linked issues.

Common use: read the complete ticket before implementing a fix.

143-tools linear get_task --task_id ENG-123

linear find_related_tasks

Find linked tasks, sub-issues, or tasks in the same project.

Common use: check whether another task already covers the same root cause.

143-tools linear find_related_tasks --task_id ENG-123

linear update_task

Update task metadata or add a comment.

Common use: leave an implementation note or move a task after completing work.

143-tools linear update_task --task_id ENG-123 --comment "Opened a PR with the fix."

linear create_task

Create a new task.

Common use: create follow-up work discovered during a code change.

143-tools linear create_task --team_key ENG --title "Add regression coverage for webhook retries" --priority high

Documents

These commands are exposed for configured document stores such as Notion.

notion search_documents

Search documents by text query.

Common use: find design docs, RFCs, postmortems, or launch plans before changing behavior.

143-tools notion search_documents --query "webhook retry policy" --limit 10

notion get_document

Fetch a document's full content.

Common use: read the authoritative product or architecture context for a change.

143-tools notion get_document --doc_id abc-123

Code review

These commands are exposed for configured code review sources such as GitHub.

github list_recent_prs

List recent pull requests with titles, authors, review status, and change size.

Common use: learn recent local patterns before editing the same area.

143-tools github list_recent_prs --state merged --limit 20

github get_pr_reviews

Get reviews and inline review comments for a PR.

Common use: inspect prior reviewer feedback so a new change follows accepted conventions.

143-tools github get_pr_reviews --pr_number 1234

CI test insights

These commands are exposed for configured CI providers such as CircleCI.

circleci list_flaky_tests

List flaky tests detected by CircleCI.

Common use: choose a flaky test to investigate when CI is unstable.

143-tools circleci list_flaky_tests --limit 25

circleci get_job_test_results

Fetch individual test results and failure messages for one CI job.

Common use: read the exact failure output for a flaky occurrence.

143-tools circleci get_job_test_results --job_number 123456

circleci get_recent_test_failures

Get recent failure occurrences for a test, including failure messages.

Common use: compare failure messages across runs before changing a test.

143-tools circleci get_recent_test_failures --test_name "TestWebhookRetries" --limit 5

Logs

Log commands use a shared logs namespace with a --provider flag. Configured providers can include victorialogs and mezmo.

logs query

Run a read-only provider-native log query over a bounded time range.

Common use: investigate recent API errors with a bounded production log search.

143-tools logs query --provider victorialogs --query 'service:api AND level:error' --since 1h --limit 100

logs context

Fetch neighboring logs around an event anchor. At least one of --id, --cursor, or --timestamp is required. Using --timestamp also requires --query.

Common use: expand from one failed request to the surrounding request lifecycle.

143-tools logs context --provider victorialogs --query 'request_id:"req_123"' --timestamp 2026-06-05T12:00:00Z --since 15m --before 25 --after 25

logs fields

List common indexed or queryable fields for a provider.

Common use: discover available fields before composing a precise log query.

143-tools logs fields --provider victorialogs --since 24h --limit 100

logs stats

Run lightweight provider-native aggregate log stats. This command appears only for providers that support stats.

Common use: group errors by service, org, or endpoint before drilling into raw logs.

143-tools logs stats --provider victorialogs --query 'level:error' --since 1h --group_by service --limit 20

Previews

Preview commands use 143's platform-controlled preview lifecycle and browser inspector. Inside a coding-agent sandbox, session-scoped commands default to CODING_SESSION_ID, so screenshots and browser checks run against the live session workspace before the branch is published. Browser diagnostics also accept an explicit --session-id or --preview-id.

preview create

Create or reuse a preview.

143-tools preview create --session-id "$CODING_SESSION_ID" --wait
143-tools preview create --repository example-org/example-app --branch feature/foo --wait

preview ensure, preview observe, and preview act

Coding-agent sessions can use the native verification loop without passing a preview or session ID:

143-tools preview ensure --wait
143-tools preview observe --path /
143-tools preview act --steps '[{"action":"click","role":"button","name":"Save"}]'
143-tools preview update --wait

observe returns screenshot reference metadata, URL, title, viewport, capture time, a bounded accessibility tree, optional bounded DOM, readiness and browser restoration status, and error-level console messages after the supplied cursor. Pass --output path/to/image.png to write the image into the workspace without keeping base64 in command output. act accepts structured actions such as navigate, click, fill/type, select, check/uncheck, press, hover, scroll, wait for selector/URL/text/readiness/network idle, coordinate click, and viewport changes, then returns the action result and a fresh observation. Navigation is restricted to the active preview origin and the repository's browser.allowed_paths policy.

Use preview control to inspect whether the agent, a human, or a pending handoff owns browser input. When login, MFA, CAPTCHA, or human judgment is required, call:

143-tools preview request_handoff --reason "MFA approval required"

This pauses agent actions until an authorized user takes control in the session preview panel and returns it. The browser URL, cookies, and local storage remain on the same session-owned context throughout the handoff.

preview status

Read status, URL, freshness, and the recommended update mode.

143-tools preview status --session-id "$CODING_SESSION_ID"

preview update

Make a session preview reflect recent workspace edits. The platform selects the fastest safe path: browser reload, soft service restart, full recycle, cold relaunch, or no-op. Config overrides escalate to full recycle.

143-tools preview update --session-id "$CODING_SESSION_ID" --wait

Browser Inspection

Use these after creating or updating a preview. Pass either --session-id or --preview-id.

143-tools preview screenshot --session-id "$CODING_SESSION_ID" --path / --viewport-w 1280 --viewport-h 720 --inline-base64 false
143-tools preview inspect --session-id "$CODING_SESSION_ID" --selector '[data-testid=save]'
143-tools preview interact --session-id "$CODING_SESSION_ID" --steps '[{"action":"click","selector":"[data-testid=save]","screenshot":true}]'
143-tools preview multi_viewport --session-id "$CODING_SESSION_ID" --path /
143-tools preview console --session-id "$CODING_SESSION_ID" --level error

Messaging

These commands are exposed for configured message sources such as Slack.

slack search_messages

Search messages by text query.

Common use: find user reports, incident discussion, or rollout context.

143-tools slack search_messages --query "checkout timeout" --limit 10

slack get_thread

Get a full conversation thread.

Common use: read the full discussion around a bug report before coding.

143-tools slack get_thread --message_id msg-456

slack send

Send a plain-text Slack message through 143's platform-managed Slack connection. This command appears only when the session or automation has the Slack notification capability.

Common use: post automation completion or status updates to a channel chosen by the automation owner.

143-tools slack send --channel-id C123 --text "Automation completed successfully."

The command returns delivery state and Slack message coordinates:

{"status":"sent","channel_id":"C123","message_ts":"1700000000.000100"}

143 workflow tools

These commands are exposed by 143 itself when the session has the matching capability.

issue create

Create a new engineering issue and return its UUID.

Common use: file follow-up work from an agent investigation.

143-tools issue create --title "Webhook retries drop idempotency key" --description "Observed while fixing ENG-123." --severity warning

pr create

Queue first-class 143 pull request creation for the current session.

Common use: open a PR through the same workflow as the app after tests pass.

143-tools pr create --draft false

This command queues the durable 143 publication workflow; it does not call the GitHub PR API from the sandbox. Sandbox GitHub API access is read-only for pull requests, while git push uses a separate repository-bound contents token.

The command returns the workflow's actual asynchronous status: review_in_progress, pr_queued, already_published, manual_publication_required, or blocked. A running review or queued publication is not a created pull request; report the returned state and wait for the session Overview to converge.

pr update

Update the title and/or Markdown description of the current session's existing primary Pull Request.

At least one of --title, --body, or --body-file is required. Prefer a file for substantial descriptions:

143-tools pr update --body-file /tmp/pr-description.md

The server verifies that the Pull Request belongs to the token-scoped session and repository, updates GitHub with the server-held App installation, preserves 143's hidden publication marker and preview footer, refreshes the local PR mirror, and records an agent audit event. The sandbox's raw GitHub token remains read-only for Pull Requests, so gh pr edit is intentionally not a substitute for this command.

eval add

Add a candidate eval task from a session launched by the eval settings bootstrap flow. This namespace is not exposed to ordinary coding sessions.

Common use: while bootstrapping evals, record a PR-derived coding task that should become a reviewed eval candidate.

143-tools eval add --pr_number 42 --pr_title "Fix checkout timeout" --base_commit_sha abc123 --solution_commit_sha def456 --solution_diff "$(git show --format= --patch def456)" --issue_description "Reproduce and fix the checkout timeout." --scoring_criteria '[{"name":"fixes-timeout","grader_type":"llm_judge","description":"The checkout path no longer times out."}]' --complexity moderate --fitness_score 0.9 --fitness_reasoning "Real regression with clear before/after behavior."

143 code review history

Read access to past automated code reviews for the session's repository, mirroring the session-history namespace. These commands exist so agents can audit how the review policy behaved on real pull requests — which reviews approved, blocked, or escalated, and on what evidence — and then propose policy adjustments. Requires the review_feedback capability.

code-review-history list

List past code reviews for the current repository, newest first. Rows are compact summaries: PR context, decision, status, risk verdict, and the policy_id of the policy version that governed the review. The full review body is only returned by get.

Common use: sample recent decisions before judging whether the policy is behaving as intended.

143-tools code-review-history list --decision blocked --created_after 2026-06-01T00:00:00Z --limit 20

code-review-history get

Get one review in full: the posted review body, every finding (severity, confidence, file and line range, and whether it was posted as an inline comment), and each reviewer agent's structured verdict. Look up by the session_id field from a list row.

Common use: inspect why a review reached its decision — compare the findings and verdicts against the diff before proposing a policy change.

143-tools code-review-history get --session_id 9b8c1c33-8ddc-4d75-8f68-f6a72f2b6c1d

code-review-history policy

Get the org's code review policy. Without flags it returns the active resolved policy (source is organization for a saved policy or default when the org has never saved one). Pass --policy_id (from a review's policy_id field) to fetch the exact historical version that governed a past review.

Common use: diff the policy version behind a run of bad decisions against the current version, then draft an improved review_instructions or automated_approval_policy for a human to apply in review settings.

143-tools code-review-history policy
143-tools code-review-history policy --policy_id 5c2f9a51-40cb-45f7-8f0d-6bc47d4e2a11

code-review-history update_policy

Apply a versioned update to the org's code review policy. Supplied config keys merge onto the active policy — omitted fields keep their current values, and the merge is recursive for nested sections (only the keys you supply change; JSON arrays are the exception and replace the current array wholesale). The write closes the iteration loop: an agent that audited past reviews can adjust the policy itself instead of asking a human to tweak the knobs.

This is the only write in the namespace and it is separately permissioned. It requires the code_review_policy_management capability at write access, which is off by default (unlike review_feedback, it is not in the recommended default grants). Org admins can grant it in capability settings, or an agent can ask for one-run approval with 143-tools capability request --capability-id code_review_policy_management --access-level write --reason "...". The grant also carries the policy read so the agent can fetch the active version its update must reference, even if review_feedback is not granted.

Safeguards on every update:

• --expected_version must match the active policy version (0 if the org has never saved one). If the policy changed since it was read, the call fails with 409 CODE_REVIEW_POLICY_VERSION_CONFLICT and the current version — re-read with policy and retry.
• --reason is required and recorded in the org audit log along with the session that made the change.
• Policies are insert-only versions; a human can review the audit trail and restore any earlier version from review settings.

Common use: after list/get show a pattern of wrong decisions, apply the corrected instructions directly.

143-tools code-review-history update_policy \
  --expected_version 7 \
  --reason "Blocked three doc-only PRs this week; policy now exempts docs-only diffs" \
  --config '{"automated_approval_policy":"Approve documentation-only changes that touch no executable code."}'