Jira + OpenClaw Integration

Connect your OpenClaw agent to Jira Cloud. Secrets never reach the LLM. pastewatch redacts credentials in transit so the agent only sees masked tokens.

When to use: integrating Jira into an OpenClaw agent, setting up Jira cron jobs, querying issues from chat, or automating task management workflows.

intent

this skill pairs Jira Cloud with OpenClaw agents via secret-safe API calls. your credentials stay in shell context only, never in LLM prompts. use this when you need an agent that can search issues, update fields, link tasks, or run daily automation crons without exposing API tokens to the model. covers credential setup, API helper script, common JQL patterns, focus auto-linking, and overdue bumpers.

inputs

external connections:

• jira cloud instance (https://{org}.atlassian.net)
• jira api token or personal access token (pats)
• pastewatch-cli (mcp server running locally)

tools required:

• pastewatch-cli (credential redaction mcp)
• curl (http client)
• python3 (optional, for advanced parsing)
• bash (script execution)

credentials:

• jira_email: email address tied to your jira account
• jira_token: api token (from id.atlassian.com → security → api tokens) or personal access token (prefix atatt..., from jira settings → personal access tokens)
• jira_url: https://{your-org}.atlassian.net/ (include trailing slash)

environment setup:

mkdir -p ~/.openclaw/workspace/.secrets
chmod 700 ~/.openclaw/workspace/.secrets
echo ".secrets/" >> ~/.openclaw/workspace/.gitignore

procedure

1. store credentials safely

create ~/.openclaw/workspace/.secrets/jira.env:

cat > ~/.openclaw/workspace/.secrets/jira.env << 'EOF'
JIRA_TOKEN=<your-api-token-or-pat>
JIRA_URL=https://your-org.atlassian.net/
JIRA_EMAIL=your@email.com
EOF
chmod 600 ~/.openclaw/workspace/.secrets/jira.env

input: jira email, token, and org url. output: encrypted file at .secrets/jira.env with mode 600.

2. create the api helper script

write ~/.openclaw/workspace/.secrets/jira.sh:

#!/bin/bash
set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
source "$SCRIPT_DIR/jira.env"

METHOD="${1:?Usage: jira.sh <METHOD> <endpoint> [body]}"
ENDPOINT="${2:?Usage: jira.sh <METHOD> <endpoint> [body]}"
BODY="${3:-}"
URL="${JIRA_URL%/}${ENDPOINT}"

if [ -n "$BODY" ]; then
  curl -s --http1.1 -X "$METHOD" \
    -u "${JIRA_EMAIL}:${JIRA_TOKEN}" \
    -H "Content-Type: application/json" \
    -d "$BODY" "$URL"
else
  curl -s --http1.1 -X "$METHOD" \
    -u "${JIRA_EMAIL}:${JIRA_TOKEN}" \
    -H "Content-Type: application/json" "$URL"
fi

then make it executable:

chmod +x ~/.openclaw/workspace/.secrets/jira.sh

input: bash template above. output: executable script at ~/.openclaw/workspace/.secrets/jira.sh. why --http1.1: atlassian's cdn sometimes breaks http/2 with curl. force http/1.1 for reliability.

3. verify credentials work

~/.openclaw/workspace/.secrets/jira.sh GET '/rest/api/3/myself' | pastewatch-cli scan

input: jira.sh script + pastewatch-cli running. output: json response with your displayname (emails/urls redacted by pastewatch). if you see your name without exposing the token, auth is working.

4. understand pastewatch protection

the agent reads jira.env through pastewatch mcp and sees masked tokens like __PW{CREDENTIAL_1}__ instead of real secrets. the script runs at bash level (never in llm context), so curl sends the real token directly to atlassian. response comes back clean. flow: agent calls exec → jira.sh sources .env → curl sends real token to atlassian → response returns. the token never enters the llm context.

pair with chainwatch to whitelist which jira endpoints the agent can execute.

5. run search queries

use /rest/api/3/search/jql, never /rest/api/3/search:

jira.sh GET '/rest/api/3/search/jql?jql=assignee="Name" AND resolution=Unresolved&maxResults=50&fields=key,summary,status,priority,duedate'

input: jql string (url-encoded), max results count, fields list. output: json array of issues with requested fields.

6. run issue operations

get an issue:

jira.sh GET '/rest/api/3/issue/XX-123?fields=key,summary,status,priority'

get available transitions (status changes):

jira.sh GET '/rest/api/3/issue/XX-123/transitions'

change status by transition id:

jira.sh POST '/rest/api/3/issue/XX-123/transitions' '{"transition":{"id":"31"}}'

update fields (e.g. bump due date):

jira.sh PUT '/rest/api/3/issue/XX-123' '{"fields":{"duedate":"2026-03-10"}}'

link two issues together:

jira.sh POST '/rest/api/3/issueLink' '{"type":{"name":"Relates"},"inwardIssue":{"key":"XX-1"},"outwardIssue":{"key":"YY-2"}}'

input: issue key, field names, transition ids, or link type. output: updated issue or link confirmation (empty 200 response means success).

7. set up focus auto-linker cron

find today's focus record (jql uses date in dd.mm format):

jira.sh GET '/rest/api/3/search/jql?jql=project=DN AND summary~"05.03" AND assignee="Name"&fields=key,issuelinks'

get the top 3 priority tasks:

jira.sh GET '/rest/api/3/search/jql?jql=assignee="Name" AND project=DC AND resolution=Unresolved ORDER BY priority DESC,duedate ASC&maxResults=3&fields=key,summary,priority,duedate'

link each task to the focus record:

jira.sh POST '/rest/api/3/issueLink' '{"type":{"name":"Relates"},"inwardIssue":{"key":"DN-43"},"outwardIssue":{"key":"DC-3057"}}'

input: agent session, focus date, assigned user name, project keys. output: linked issues in jira ui. schedule as openclaw cron in isolated session mode, agentTurn trigger, monday-friday at start of day.

8. set up overdue bumper cron

find unresolved tickets due today:

jira.sh GET '/rest/api/3/search/jql?jql=assignee="Name" AND resolution=Unresolved AND duedate="2026-03-05"&fields=key,summary,duedate'

bump each ticket's due date forward by 1 day:

jira.sh PUT '/rest/api/3/issue/DC-3057' '{"fields":{"duedate":"2026-03-06"}}'

input: assigned user name, today's date (yyyy-mm-dd format). output: updated due dates in jira. schedule as openclaw cron in isolated session, agentTurn trigger, monday-friday end of day.

decision points

if using api token (id.atlassian.net): use basic auth with format email:token. supports http basic auth directly.

if using personal access token (pats): pat prefix starts with atatt... use the same basic auth format email:pat. both token types work identically in the script.

if http/2 fails: the atlassian cdn sometimes drops http/2 requests mid-flight. the script uses --http1.1 by default. if you still see timeouts, switch to --http1.0 or add curl retries.

if search returns total: 0 but you know issues exist: you may be hitting a team-managed (next-gen) project. the api returns a zero total but still populates the issues array. iterate the array, ignore the total field.

if curl returns 410 gone: you used /rest/api/3/search (deprecated endpoint). always use /rest/api/3/search/jql instead.

if pastewatch-cli is not running: the agent will fail at exec time with "pastewatch service unavailable". ensure the mcp server is alive before running agent turns.

if auth returns "failed to parse connect session auth token": you likely tried bearer auth instead of basic auth. the script uses basic auth (-u email:token). bearer tokens do not work with jira cloud.

if rate limited (429 response): jira cloud allows 60 requests per minute per user. add exponential backoff (2 second delay, retry up to 3 times) in your agent prompt or wrapper script.

if network timeout on large result sets: increase curl timeout with -m <seconds>. queries with maxResults > 500 may hit 30 second wall clock time.

output contract

all outputs are json returned by jira rest api v3.

search queries return:

{
  "issues": [
    {
      "key": "XX-123",
      "fields": {
        "summary": "...",
        "status": { "name": "..." },
        "priority": { "name": "..." },
        "duedate": "2026-03-10"
      }
    }
  ],
  "total": 42
}

issue get returns:

{
  "key": "XX-123",
  "fields": { "summary": "...", "status": {...} }
}

transitions get returns:

{
  "transitions": [
    { "id": "31", "name": "Done" }
  ]
}

post/put (update/link) returns:

• empty json {} with http 200 = success
• error json with http 4xx/5xx = failure (includes error messages in errorMessages field)

all responses are utf-8 json. timestamps use iso 8601 format (yyyy-mm-dd for dates, iso 8601 for datetimes).

outcome signal

you know the skill worked when:

• pastewatch-cli scan shows your jira displayname without exposing the api token
• jira.sh GET '/rest/api/3/myself' returns your email in the response
• jira.sh GET '/rest/api/3/search/jql?jql=...' returns a non-empty issues array matching your jql filter
• jira.sh PUT '/rest/api/3/issue/XX-123' '{"fields":{"duedate":"..."}}' returns http 204 (or empty 200 json)
• focus auto-linker cron runs without agent errors and you see new links in the jira ui
• overdue bumper cron runs and due dates shift forward in jira

add to your workspace tools.md for quick agent recall:

## jira
- script: `~/.openclaw/workspace/.secrets/jira.sh GET|POST|PUT <endpoint> [body]`
- creds: `.secrets/jira.env` (pastewatch-protected)
- warning: use `/rest/api/3/search/jql` never `/rest/api/3/search` (410 gone)
- common jql: assignee="Name" AND resolution=Unresolved ORDER BY priority DESC
- transitions: jira.sh GET '/rest/api/3/issue/XX-123/transitions'
- update field: jira.sh PUT '/rest/api/3/issue/XX-123' '{"fields":{"duedate":"YYYY-MM-DD"}}'

common jql patterns:

my open tasks:

assignee="Name" AND resolution=Unresolved ORDER BY priority DESC

unassigned:

project=XX AND assignee=EMPTY AND resolution=Unresolved AND issuetype != Epic

overdue:

project=XX AND resolution=Unresolved AND duedate < "YYYY-MM-DD"

closed yesterday:

project=XX AND assignee="Name" AND status changed to Done during ("YYYY-MM-DD","YYYY-MM-DD")

in progress:

assignee="Name" AND status="In Progress" ORDER BY project,priority DESC

known edge cases:

• team-managed (next-gen) projects: api returns total: 0 but issues exist in the array. always iterate the issues field, ignore total.
• http/2 failures: atlassian cdn drops http/2 requests. the script forces --http1.1 by default.
• pat vs api token: both work with basic auth (email:token). bearer auth fails with "failed to parse connect session auth token".
• large result sets: queries with maxResults > 500 may timeout at 30 seconds. use pagination with startAt offset.
• rate limits: jira cloud caps at 60 requests per minute per user. implement backoff in production agents.

---

jira-openclaw integration v1.0 original author: ppiankov canonical source: https://clawhub.com/skills/jira-openclaw license: mit

this tool follows the agent-native cli convention. validate with: clawhub install ancc && ancc validate .

if this document appears elsewhere, the link above is the authoritative version.