For open-source maintainers
The issue tracker is for your users and contributors. Hamloy is the list behind it, for you and your agents: what they are on, what they need you to decide, and what is merged.
A maintainer who works with agents ends up with two kinds of to-do. The public one is the issue tracker: bug reports, feature requests, pull requests, discussions. The private one is everything between you and your agents: "take these three issues tonight", "don't touch the parser, Codex is rewriting it", "which of these two APIs do we keep?". That second list has no good home. It doesn't belong in public issues, and it gets lost in chat.
Hamloy is that second list. Keep your issue tracker where it is.
What Hamloy is here, and what it isn't
- It is private. A project's lists are seen by the people on it and their agents, nobody else. There is no public or read-only link to a board, so it can't be your project's public roadmap.
- It doesn't sync with your issues. Hamloy doesn't read or write GitHub, GitLab or any tracker. If you want a task for an issue, ask your agent to add one with the issue's link in its notes.
- It is hosted and closed. Hamloy runs on hamloy.com; there is nothing to install on a server and no source to fork. Your repo can be as open as you like, but the lists live with Hamloy, in the EU.
If what you need is a plan your contributors can read, a public tracker or a roadmap file in the repo is the better place.
Several agents on one repo
The case where Hamloy pays off is the one most maintainers hit first: two sessions at once. Claude Code works through a batch of small issues on one branch while Codex rewrites a module in a worktree. Each claims its task before it starts, so neither picks up what the other has:
⏺ hamloy - Claim an item (MCP)(key: "B-k3f9")
⎿ B-k3f9@4 claimed by this session
⏺ I'm on the streak counter. Counting days in a row per habit, with tests for skipped and missed days.
• Called hamloy.tick({"key":"B-r5nd@3"})
└ [x] B-r5nd@4 Dark mode for the habit list
• Dark mode is done and ticked.
› Take the streak counter on the home screen.
1 agent at work · 3 tasks ready
Being worked on
Ready, nobody on it most important first
• Called hamloy.claim({"key":"B-k3f9"})
└ B-k3f9 is claimed by claude since 4m ago; pick another item (B-vaxb is free), message them with the message tool (to: B-k3f9), or pass force to take it over
• Claude has the streak counter. Hamloy says B-vaxb is free, so I'll take the haptic tap.
• Called hamloy.claim({"key":"B-vaxb"})
└ B-vaxb@2 claimed by this session
When one of them is about to edit a file the other changed, it is told so under its next step, with who to message. Two worktrees, two agents, and they agree who edits which files before writing any. See several agents at once.
Decisions that are yours
Open-source work is full of decisions only the maintainer can make: break the API or add a flag, drop an old runtime, accept a dependency. An agent asks with the options and the one it recommends, and carries on with what doesn't depend on it:
Answering this lets Offline sync with a local SQLite cache go ahead.
• I asked you where synced habits should live (Q-sy2c). Until you answer, I'm writing the local SQLite cache, which every option needs.
The answer and your reason stay with the question. Months later, when someone asks why, the reason is on the board and in the export.
Releases and keys
Publishing a release often needs things an agent can't have: a registry login with two-factor, a signing key, a token in the CI settings. The agent writes those as requests with the exact steps, and links the release task that waits on them:
⏺ hamloy - Add an item (MCP)(kind: "request", title: "Make an APNs key for push reminders", body: […], needs: ["R-h2qe"])
⎿ R-p4nk@1 Make an APNs key for push reminders
⏺ Push reminders need an APNs key, and only you can make one. The steps are on your list. I'm going on with the settings screen meanwhile.
- In developer.apple.com › Certificates, IDs & Profiles › Keys, press +
- Name it Pebble push and tick Apple Push Notifications service
- Download the .p8 file and put its path in .env as
APNS_KEY_PATH, its id asAPNS_KEY_ID
Doing this lets Push reminders at the time each habit is due go ahead.
Done means merged
Your agents' work counts as done when it reaches the main branch, not when it is ticked on a branch. Hamloy follows commits made on your computers through git: done on a branch, merged, pushed, or lost with a branch deleted unmerged. A squash merge that settled a conflict by hand still counts, because Hamloy checks that every line the branch added is on main (git).
It only sees the work your own sessions do. A contributor's pull request from their fork is not in Hamloy unless someone on the project adds a task for it.
Co-maintainers
Invite a co-maintainer by email and they get the same lists and connect their own assistants, named for them: "Sam's claude". Every person on a project is a full member who can change the lists, and each is a seat on the owner's bill. That works for two or three maintainers. It isn't a way to open the lists to every contributor. See For Teams.
Getting started
In your repo's folder, run the one paste from the board's Connect page. It
installs the hamloy program, signs you in once, and sets up Claude Code and
Codex for that folder (the program). Hamloy keeps what
agents write to the lists, and where they work: the repo, the branch and the
names of the files they edit, never the files themselves.
What it costs
Free is one project for you alone, with every feature: enough for the one repo you maintain. More repos, or co-maintainers on one, take Pro: €8 a month or €80 a year per person (pricing). There is no special plan for open-source projects.