From curl to the Backlog CLI 'bee' — Making AI Agent Integration One Step Easier

Nulab's volunteer-maintained open-source tool 'bee' provides a GitHub CLI-style interface for Backlog, reducing API key exposure and simplifying AI agent integration. The tool, requiring Node.js 20.18+, supports commands like 'bee issue list' and 'bee api', but its '--status' filter expects numeric IDs, not 'open'.

Last time, in Issuing a Backlog API Key to Drive It from AI Agents https://codenote.net/en/posts/backlog-api-key-for-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 https://github.com/nulab/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 https://github.com/nulab/bee is GitHub CLI https://cli.github.com/ 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 https://github.com/nulab/bee itself calls out, it is volunteer-maintained OSS MIT licensed https://github.com/nulab/bee/blob/main/LICENSE . That said, it is driven by Nulab folks, and it goes through the same official Backlog REST API https://developer.nulab.com/docs/backlog/ 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 https://nodejs.org/ 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 https://cli.github.com/manual/ . 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 https://github.com/nulab/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.