Tadashi Shigeoka· Mon, August 3, 2026 I use Backlog as my day-to-day project management tool. I recently tried plugging AI agents (Claude Code, Codex, and Hermes Agent) into it so they could create, update, comment on, and list issues on my behalf. It works at production level.
The mechanism itself is simple: I issue a Backlog API key from the official personal settings screen and hand it to the agents to call the REST API. Doing this in earnest, though, surfaced a couple of things I’d like Backlog to improve. This post covers both the setup that worked and the two rough edges I ran into.
Why I Want AI Agents to Drive Backlog #
If Backlog stays a separate silo from my editor and chat tools, small handoffs pile up:
- Once an implementation is done, I have to leave the terminal to update the issue status in the Backlog web UI
- Requests that arrive over Slack or chat have to be transcribed into Backlog issues later, by hand
- The weekly rollup (“issues we moved this week”) gets stitched together by searching in the browser and copy-pasting
If the AI agent can talk to Backlog directly, all of that goes away. The target picture is: I tell the agent “close the Backlog issue that maps to this PR and paste the commit URL as a comment,” and everything else happens over the API without me touching the UI.
Issuing a Backlog API Key #
The Backlog API key is issued from personal settings, per the official guide at Backlog Help: How to register SSH public and API keys in Backlog. The flow is:
- Log in to your Backlog space, click the avatar in the top-right, and open “Personal Settings”
- Choose “API” from the left menu
- Add a memo describing what the key is for and press “Register”
- Copy the newly issued API key
The API key is scoped to a single space and a single user. It inherits everything that user is allowed to do inside Backlog: an admin-issued key can do admin-level things, a general-member-issued key gets general-member-level access.
Handing the API Key to the Agent #
Instead of pasting the key into a prompt, it’s safer to put it in an environment variable and let the agent read it from there.
The Backlog REST API is documented at Backlog API documentation. The basic shape is a query-parameter API key:
Claude Code and Codex can invoke this straight through their shell. For a more structured setup, you can front the API with a Backlog-oriented MCP server so the agent gets typed operations instead of raw HTTP.
What I Got Working #
From any of Claude Code, Codex, or Hermes Agent, the following now runs in a single prompt:
- Listing issues (filtered by project, assignee, status, etc.)
- Creating issues, assigning them, and setting due dates
- Transitioning issue status (Open, In Progress, Resolved, Closed)
- Adding comments and Git integration references to issues
- Listing wiki pages and reading their content
Flows like “when this PR merges, close the corresponding Backlog issue,” “turn this Slack request into a properly summarized Backlog ticket,” and “summarize the issues that got comments this week” are largely automatable now.
What I’d Like Backlog to Improve #
At the same time, running this seriously against an AI agent surfaces two places where Backlog’s API-key implementation feels one step short.
1. The API Key Stays Visible as Plaintext in the Browser
Backlog’s API screen shows the issued key in plaintext, and keeps showing it every time you revisit that settings page. Any future visit shows the raw key.
That maps almost directly onto real risk. Opening personal settings during a pair-programming session, sharing your screen, or taking a screenshot for a support ticket can all leak the key. It’s manageable operationally, but the current spec doesn’t do the “cannot accidentally leak this” work for you.
What I’d like to see instead is one of:
- Show the plaintext key only at issue time, then mask it (the same pattern as GitHub Personal Access Tokens) - Show only the last four characters on the list screen, and reveal the plaintext only for the moment a “Show” button is pressed
- Log an audit event whenever the plaintext is revealed
2. The API Key’s Permissions Cannot Be Scoped Down
The second one is scoping. Today, an API key inherits the entire Backlog-side permission set of the user that issued it. There is no way to narrow it further at key-issue time.
-
Limit the key to a specific project
-
Make the key read-only
-
Allow issue creation and comments, but forbid deletion
-
Mix modes: wiki read-only, issues read/write None of that can be expressed on the key itself. What I actually want for an agent-facing key is the least-privilege model that GitHub does with fine-grained personal access tokens, that Slack does with app scopes, and that AWS does with IAM policies.
To approximate this on Backlog today, I fall back to workarounds on the user side:
- Create a dedicated agent-only Backlog user
- Add that user only to the projects the agent should touch
- Give that user a lower Backlog role (General User or Reporter) so destructive operations are impossible
- Issue the API key from that constrained account
This does help, but not being able to scope the key itself means any leak still has a wider blast radius than it needs to under an AI-agent operating model.
Summary #
Backlog is production-viable for AI-agent-driven issue management via the REST API. Claude Code, Codex, and Hermes Agent all drive it well, and the manual bridging between “the implementation side” and “the issue-management side” largely disappears.
At the same time, the API key’s plaintext display and the lack of scoping are two spots I’d love to see improved for the AI-agent era. Until they land, the practical pattern is a dedicated agent-only Backlog user with minimum project memberships, and I’ll keep waiting for the day fine-grained scopes are supported natively.
That’s all from wiring Backlog into Claude Code, Codex, and Hermes Agent via a Backlog API key, from the Gemba.