Last time, in Issuing a Backlog API Key to Drive It from AI Agents, I walked through issuing a Backlog API key and letting Claude Code or Codex hit the REST API through curl. It works, but once you actually live with it, small frictions pile up:
- Even if the API key sits in an environment variable, it still shows up as
apiKey=...
in the URL query, and that leaks into command history and shared scripts - The response is raw JSON, so before handing it to the agent I keep re-deciding whether to pipe it through
jq
- Common lookups like “my open issues” force me to reassemble the endpoint and query parameters every time
A Nulab volunteer project has taken care of that abstraction layer: bee. This post is what I got out of putting it in front of my Backlog + AI-agent setup.
What bee Is #
In one sentence, bee is GitHub CLI (gh
) for Backlog. It exposes Backlog’s core resources (projects, issues, wikis, notifications, the dashboard) through a gh issue list
-style command surface.
One important caveat: bee is not an officially supported Nulab product. As the README itself calls out, it is volunteer-maintained OSS (MIT licensed). That said, it is driven by Nulab folks, and it goes through the same official Backlog REST API I described last time, so the auth story does not change. The previous conclusion, “run an agent-only Backlog user and issue an API key for it,” carries over directly onto bee.
Install and First-Time Auth #
bee ships as an npm package and requires Node.js 20.18 or later. First-run auth is per space. Both browser-based OAuth and the API key from the previous post work; for agent use, the API key path is usually the easier fit.
If you juggle multiple Backlog spaces, bee auth switch
flips the active one. Once auth is in place, every other subcommand picks up the credentials implicitly.
How bee Changes the Agent Story #
The biggest shift versus raw curl is that the API key stops showing up on the command line. bee’s credentials live in a local config file, so any shell command handed to Claude Code or Codex no longer needs apiKey=xxx
in it. The structural risk of an API key leaking into an agent prompt or shell history drops sharply.
The second shift is output handling. The default output is human-readable, but most subcommands accept --json
and return machine-readable JSON. Even if you still let the agent parse the output, the shape is far more stable than hand-rolled REST.
For the times you still want raw REST (poking at a newer Backlog endpoint, say), bee api <endpoint>
lets you hit any endpoint while reusing the stored credentials. Safer than a fresh curl one-liner, and shorter.
Common Use Cases #
The subcommands listed by bee --help
(auth
, project
, issue
, document
, notification
, pr
, repo
, team
, user
, wiki
, category
, milestone
, issue-type
, space
, status
, star
, watching
, dashboard
, browse
, api
, completion
) map almost one-to-one onto Backlog’s resources. The operations you actually want an agent to do usually fall inside that list.
For a “what is on my plate” glance across notifications and issues, one line is enough: To inspect a single issue, pass the Backlog issue key directly:
Creating an issue or leaving a comment reads much like gh issue create
:
Wiki reads stay in the terminal too:
The Gotcha: --status open #
Does Not Work
With all that said, the first thing I tripped over in production was bee issue list
’s status filter. GitHub-CLI reflexes make you want to write:
That does not work. bee’s --status
expects a numeric status ID, so passing "open"
fails with Invalid type: Expected number but received NaN
.
Backlog’s built-in statuses are 1 = Open
, 2 = In Progress
, 3 = Resolved
, 4 = Closed
. To get the equivalent of “open” (unfinished issues), pass -S
(status ID) multiple times:
-a @me
is a nice CLI-only shorthand for “issues assigned to me.” Projects can define custom statuses outside the standard four, so it is worth pinning down the IDs beforehand:
Watch the letter casing too. -S
is status ID and -a
is assignee, which diverges slightly from the gh conventions. If you plan to store agent prompts or snippets, templating this makes future you happier.
Wrap-Up #
Driving Backlog from AI agents already works on the “agent-only user + API key” approach from the previous post. Layering bee on top of that keeps the API key off the command line, gives you structured output, and still lets you drop down to raw REST via bee api
when you need to.
bee is volunteer-maintained OSS from Nulab, not an officially supported product, so it should not be treated with the same expectations as a paid tool. But as a CLI it is polished, and it takes one clear step of friction out of AI-agent-driven Backlog operations. For now my baseline setup is “dedicated agent user + bee,” and I will keep an eye on both bee and Backlog’s own API-key implementation as they mature.
That’s all from moving off raw curl onto the Backlog CLI ‘bee’ and making AI agent integration one step easier, from the Gemba.