Sentry (Read-only Observability)

Quick start

• •If not already authenticated, ask the user to provide a valid SENTRY_AUTH_TOKEN (read-only scopes such as project:read, event:read) or to log in and create one before running commands.
• •Set SENTRY_AUTH_TOKEN as an env var.
• •Optional defaults: SENTRY_ORG, SENTRY_PROJECT, SENTRY_BASE_URL.
• •Defaults: org/project {your-org}/{your-project}, time range 24h, environment prod, limit 20 (max 50).
• •Always call the Sentry API (no heuristics, no caching).

If the token is missing, give the user these steps:

1. •Create a Sentry auth token: https://sentry.io/settings/account/api/auth-tokens/
2. •Create a token with read-only scopes such as project:read, event:read, and org:read.
3. •Set SENTRY_AUTH_TOKEN as an environment variable in their system.
4. •Offer to guide them through setting the environment variable for their OS/shell if needed.

• •Never ask the user to paste the full token in chat. Ask them to set it locally and confirm when ready.

Core tasks (use bundled script)

Use scripts/sentry_api.py for deterministic API calls. It handles pagination and retries once on transient errors.

Skill path (set once)

export CODEX_HOME="${CODEX_HOME:-$HOME/.codex}"
export SENTRY_API="$CODEX_HOME/skills/sentry/scripts/sentry_api.py"

User-scoped skills install under $CODEX_HOME/skills (default: ~/.codex/skills).

1) List issues (ordered by most recent)

python3 "$SENTRY_API" \
  list-issues \
  --org {your-org} \
  --project {your-project} \
  --environment prod \
  --time-range 24h \
  --limit 20 \
  --query "is:unresolved"

2) Resolve an issue short ID to issue ID

python3 "$SENTRY_API" \
  list-issues \
  --org {your-org} \
  --project {your-project} \
  --query "ABC-123" \
  --limit 1

Use the returned id for issue detail or events.

3) Issue detail

python3 "$SENTRY_API" \
  issue-detail \
  1234567890

4) Issue events

python3 "$SENTRY_API" \
  issue-events \
  1234567890 \
  --limit 20

5) Event detail (no stack traces by default)

python3 "$SENTRY_API" \
  event-detail \
  --org {your-org} \
  --project {your-project} \
  abcdef1234567890

API requirements

Always use these endpoints (GET only):

• •List issues: /api/0/projects/{org_slug}/{project_slug}/issues/
• •Issue detail: /api/0/issues/{issue_id}/
• •Events for issue: /api/0/issues/{issue_id}/events/
• •Event detail: /api/0/projects/{org_slug}/{project_slug}/events/{event_id}/

Inputs and defaults

• •org_slug, project_slug: default to {your-org}/{your-project} (avoid non-prod orgs).
• •time_range: default 24h (pass as statsPeriod).
• •environment: default prod.
• •limit: default 20, max 50 (paginate until limit reached).
• •search_query: optional query parameter.
• •issue_short_id: resolve via list-issues query first.

Output formatting rules

• •Issue list: show title, short_id, status, first_seen, last_seen, count, environments, top_tags; order by most recent.
• •Event detail: include culprit, timestamp, environment, release, url.
• •If no results, state explicitly.
• •Redact PII in output (emails, IPs). Do not print raw stack traces.
• •Never echo auth tokens.

Golden test inputs

• •Org: {your-org}
• •Project: {your-project}
• •Issue short ID: {ABC-123}

Example prompt: “List the top 10 open issues for prod in the last 24h.” Expected: ordered list with titles, short IDs, counts, last seen.