issuebeam
Connect AI agents directly to GitHub Issues
Been shipping fast with Cursor and Claude Code lately, and kept running into the same annoying thing: I'd spot a bug or think of a feature mid-session, mention it in the chat, and then two days later it's just... gone. Buried in chat history I'll never scroll back through.
So I built issuebeam. It's a small Python CLI that lets your AI agent create/manage GitHub Issues directly, instead of just talking about them. You tell Cursor or Claude "open an issue for this", and it actually does it — right labels, right repo, no copy-pasting into GitHub yourself.
Kept it deliberately boring on the tech side: standard library only (urllib, argparse, pathlib), no gh CLI dependency, works the same on Windows/Mac/Linux. There's an adopt.py script that drops the setup into any existing repo along with instructions the AI reads (AGENTS.md).
Open source, MIT licensed. Still early, adding features as I hit friction myself.
Curious if others have hit the same "AI chat as graveyard for bugs" problem, or found different ways around it.
8 Comments
The
adopt.pyidea is my favorite part. It feels like you optimized for "just make this work in my existing repo" instead of asking people to change how they build.I can easily picture someone asking ChatGPT "how do I stop Cursor from forgetting bugs I mention in chat" and landing on issuebeam before they've ever heard the name. If what they find immediately looks like something other developers are already using it has a much better chance of becoming part of their workflow.
Have you seen anyone adopt it in a repo you don't have any connection to yet or is it still mostly people who've been following the project?
Thanks! That was exactly the idea behind
adopt.py—I wanted something that could be dropped into an existing repo with almost no friction.I only launched the project very recently, so I don't know of any completely independent adoptions yet. To be honest, I mainly built it for myself and decided to share it in a few developer communities to see whether the idea resonates with other people.
I'm also aware there are official GitHub tools and MCP servers that are probably much more capable. I'm not really trying to compete with those—this is more of an open-source portfolio project that solves a problem I personally ran into.
That actually makes sense. Early on, proving that the problem resonates is probably more valuable than trying to compete feature-for-feature with the official tools.
One thing I'd be thinking about is discoverability beyond the developer communities you're already posting in. A lot of developers now ask ChatGPT or other AI assistants for tools before they search GitHub directly. If IssueBeam starts getting referenced outside your own posts through technical write-ups, community discussions, or other trusted sources it has a much better chance of becoming something people (and AI) recommend naturally.
Have you given much thought to building that kind of external authority, or are you mainly focused on improving the product first?
I like that you're treating AI conversations as an unreliable workspace rather than a reliable source of truth.
The interesting problem isn't losing bugs—it's losing decisions. The moment something deserves to survive the conversation, it probably belongs in the team's workflow instead of the chat history.
I like that perspective. I think the core problem is that AI chats are great for brainstorming, but they're a poor place to keep anything that actually matters.
For me, GitHub Issues were the most natural destination because they're already part of the development workflow. If a bug, feature idea, or task comes up during a conversation with the AI, it shouldn't stay in the chat—it should become something the project can actually track.
I think that's the more interesting direction.
Your reply left me thinking about one consequence of treating conversations as temporary and workflows as permanent. It seems small at first, but it has much wider implications than I initially realized.
I don't think I can explain the reasoning properly in a thread without oversimplifying it.
If you're open to it, what's the best email to reach you on?
Just to be clear upfront: issuebeam is an open-source side project with no budget and no commercial expectations, so I wouldn't want to waste your time talking about product positioning or messaging.
The reason I reached out is different. Your comment sparked a line of thinking that I don't think fits well in an Indie Hackers thread, and I'd genuinely like to explore it with you.
If you're interested, feel free to reach out at info@antoniotrento.net.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.