I have worked with both technical and non-technical individuals throughout my career. One thing I have consistently found valuable is the ability to take a decision-maker’s “wants,” shape them into something technically achievable, and then translate those requirements to the engineers and data scientists responsible for building the solution. This is often a slow process with a lot of back-and-forth between leaders, myself, and development teams. Agentic development workflows have the potential to change this process. AI is not replacing the need for good communication and discussion, but it could reduce friction and streamline processes.
In this post, I will walk through how to use Jira, Bitbucket, and Codex to take a Jira ticket and turn it into implemented code changes using an agentic workflow. This is often referred to as a “one-shot” pass: giving the model enough context to make a meaningful implementation without constant intervention.
These workflows can save a significant amount of time and, more importantly, allow engineers to experiment with development automation before introducing token-based CI/CD pipelines where costs can spiral out of control.
This post is a little more technical and assumes you already have the following installed:
- VS Code (with the appropriate extensions)
- git
- codex-cli
The objective is not to build a perfect autonomous workflow, but to show you how to build a reproducible process that accelerates development, while helping you understand what the agent is actually doing before moving to a more hands-off CI/CD pipeline.
Setup
First, assuming you have codex-cli installed, run the following command in your terminal:
codex login
This will open a webpage for you to log in. To verify you are using the web login, run the following:
codex login status
and you should see Logged in using ChatGPT. This ensures you are not using the API-based token pricing, instead it behave similarly to the Codex VS Code extension.
Next, connect codex-cli to Atlassian’s MCP server by running:
codex mcp login atlassian
A browser window will open asking you to authorize access.
Next you will need to review your codex configuration to make sure you do not set autonomous agents loose on your computer. I use a Mac and my config is located under ~/.codex/config.toml. It looks like this:
model = "gpt-5.4-mini"
model_reasoning_effort = "medium"
model_verbosity = "low"
personality = "pragmatic"
sandbox_mode = "workspace-write"
approval_policy = "on-request"
[mcp_servers.atlassian]
url = "https://mcp.atlassian.com/v1/mcp"
[tui.model_availability_nux]
"gpt-5.5" = 4
model, model_reasoning_effort, and model_verbosity control how many tokens you will use with each step. I suggest these settings when starting out as if you use gpt-5.5 and extra-high you will burn through your five hour allotment pretty quick.
sandbox_mode is set to “workspace-write”. This means it can only read/write in the current workspace/repo. This means it will not start installing other packages fon your system. Other options are read-only (good for code review) and danger-full-access (good in a CI/CD setting but probably not on your personal machine).
Lastly is approval_policy, which is set to “on-request”. This means if there is something risky, like an rm command, it will ask you first. The following is safe and yet productive:
sandbox_mode = "workspace-write"
approval_policy = "on-request"
This is the more fun YOLO option:
sandbox_mode = "danger-full-access"
approval_policy = "never"
Running the workflow
First, you will need to make a script to execute the workflow. I provide some detail on creating a script here. After this, based on my script, you need to create a branch from your ticket and the run your script in the cli. The following section outlines how to do this in VS Code.
Creating a branch from a Jira ticket
The Atlassian plugin is great for Jira tickets. Too often, junior developers make branches that are not tied properly to their tickets. Using this plugin you can ensure it is done properly each time. First select the extension and the ticket.
Next right-click and select “start work on Jira issue”
Lastly, create the branch
You can then confirm that you are on a branch using standard git commands.
Running the agentic development workflow
Now you can run your agentic development workflow. I provide a script here that does just that; however, you should customize based on your own likes/dislikes.
Here is my script for executing a Jira ticket. This script is for updating an application. When I develop applications, I typically run them locally inside Docker containers. As such, my codex script does the same. I do this so the agent is able to validate its changes. The majority of the dependencies are not installed locally so the agent would not able to properly test or verify changes.
To execute my script, you can run the following command (just adjust the service and ticket number as needed):
codex-jira frontend SCRUM-6
With the above I am running ticket SCRUM-6 and it is for the frontend. Now you do not need to specify the service you are working one, but this does reduce the number of tokens used (nominal at best, but is an example of controlling your costs). If you read through the script you can see there is a basic workflow that does the following:
- Makes sure you have the files you need
- Checks your branch
- Brings up your docker-compose-dev.yml
- Lets Codex do its thing
- Uses git to push your changes back to your repo
Token discipline
In my script you see a section Token discipline. This is one of the most important parts of the workflow.
Token discipline:
- First fetch only the Jira summary, description, acceptance criteria, priority, labels, and latest 5 comments.
- Do not fetch attachments, full history, linked issues, changelogs, or large remote content unless clearly required.
- If more Jira context is needed, fetch it narrowly and explain why.
- Keep tool results summarized.
- Do not paste large Jira content into summaries or comments.
There are a few key points to understand. First, context is expensive. Everything it does consumes tokens. If you do not scope the workflow the agent could quickly analyze irrelevant files, wasting tokens. Second, MCP integrations are powerful, but if you do not constrain them they too might pull and analyze unnecessary information. Third, narrow context windows generally produce better results. The more focused the instructions and context, the less likely the agent is to drift toward unnecessary tasks.
Summary
For this ticket, which is adding a dark mode button I used 38,238. If I was using token-based pricing this would have probably cost 6 cents. Not all that bad. This was a simple feature, but lets 10x it for a “harder problem” -> 60 cents. Now lets say one developer runs 20 pipelines a day, 5 days a week, for a month. That would give us $240 monthly cost. If you had 10 such engineers you would have a cost of $2400 a month. Seems like a lot, but not if you have ever tried to hire a cleared engineer…
Appendix
Creating script to run locally
There are many options for scripting an agentic development workflow, I save my specialized scripts for reuse under ~/bin but you can really save them anywhere. Just make sure you make your script executable and ensure the directory where you make your script is in your PATH variable.
Without going into excruciating detail, here are the steps I follow to make a script that can then be ran in a cli.
vim ~/bin/codex-jira
Add the script below and exit with saving. This requires some basic vim commands. Next run:
chmod +x ~/bin/codex-jira
Next update your PATH variable if you have not already:
echo 'export PATH="$HOME/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
Now if you type which codex-jira you should see the path to your file.
codex-jira script
#!/usr/bin/env bash
set -euo pipefail
COMPOSE_FILE="${COMPOSE_FILE:-docker-compose-dev.yml}"
SERVICE_ARG="${1:-}"
ISSUE_ARG="${2:-}"
if [[ "$SERVICE_ARG" =~ ^(frontend|backend|web|client|ui|api|server|app)$ ]]; then
CODEX_SERVICE="$SERVICE_ARG"
ISSUE_KEY="$ISSUE_ARG"
else
CODEX_SERVICE="frontend"
ISSUE_KEY="$SERVICE_ARG"
fi
# Auto-detect issue key from branch if not provided
if [ -z "$ISSUE_KEY" ]; then
ISSUE_KEY="$(git branch --show-current | grep -oE '[A-Z]+-[0-9]+' || true)"
fi
if [ -z "$ISSUE_KEY" ]; then
echo "Methods to use this script:"
echo " codex-jira PROJ-123"
echo " codex-jira frontend PROJ-123"
echo " codex-jira backend PROJ-123"
exit 1
fi
if [ ! -f "$COMPOSE_FILE" ]; then
echo "Compose file not found: $COMPOSE_FILE"
exit 1
fi
CURRENT_BRANCH="$(git rev-parse --abbrev-ref HEAD)"
SERVICES="$(docker compose -f "$COMPOSE_FILE" config --services)"
if ! printf '%s\n' "$SERVICES" | grep -qx "$CODEX_SERVICE"; then
echo "Service '$CODEX_SERVICE' not found in $COMPOSE_FILE"
echo
echo "Available services:"
printf ' - %s\n' $SERVICES
exit 1
fi
echo "Running Codex for $ISSUE_KEY"
echo "Branch: $CURRENT_BRANCH"
echo "Compose: $COMPOSE_FILE"
echo "Service: $CODEX_SERVICE"
echo
docker compose -f "$COMPOSE_FILE" up -d "$CODEX_SERVICE"
codex exec --sandbox workspace-write "
Use the Atlassian MCP server to read Jira issue ${ISSUE_KEY}.
You are on local git branch: ${CURRENT_BRANCH}.
Codex is running locally on the host.
The application dependencies live in Docker Compose service: ${CODEX_SERVICE}.
The compose file is: ${COMPOSE_FILE}.
Environment rules:
- You may edit files locally.
- Do not install app dependencies on the host.
- Do not run package managers, tests, linters, framework CLIs, or app commands directly on the host.
- Run dependency-aware commands through Docker Compose:
docker compose -f ${COMPOSE_FILE} exec ${CODEX_SERVICE} <command>
- If the ticket clearly belongs to a different service, stop and say exactly which service to rerun with.
Token discipline:
- First fetch only the Jira summary, description, acceptance criteria, priority, labels, and latest 5 comments.
- Do not fetch attachments, full history, linked issues, changelogs, or large remote content unless clearly required.
- If more Jira context is needed, fetch it narrowly and explain why.
- Keep tool results summarized.
- Do not paste large Jira content into summaries or comments.
Workflow:
1. Understand the ticket before coding.
2. Determine whether it affects backend, frontend, or both.
3. Inspect the smallest relevant part of the repo.
4. Before editing, state a brief implementation plan.
5. Implement ONLY what is required.
6. Follow existing code patterns and conventions.
7. Make minimal, safe changes.
8. Do NOT refactor unrelated code.
9. Run relevant tests through Docker Compose.
After implementing:
- Summarize changed files and behavior in 5 bullets or fewer.
- Add a concise comment to Jira issue ${ISSUE_KEY} with that summary.
- Do NOT include unnecessary detail.
Constraints:
- Do not create a new branch.
- Do not open a pull request.
- Do not modify unrelated files.
"
echo
echo "Codex finished."
echo
if git diff --quiet && git diff --cached --quiet; then
echo "No changes to commit."
exit 0
fi
echo "Changed files:"
git status --short
echo
git add -A
git commit -m "${ISSUE_KEY}: fix ticket"
git push -u origin HEAD