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:

• Create a Sentry auth token: https://sentry.io/settings/account/api/auth-tokens/

• Create a token with read-only scopes such as project:read , event:read , and org:read .

• Set SENTRY_AUTH_TOKEN as an environment variable in their system.

• 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.