Security

Everything goes over HTTPS (browsers are told to use only HTTPS for agentmingo.com and its subdomains), and the app's connection to its database is encrypted too. Each page sends a Content Security Policy that runs only the scripts AgentMingo put on it (marked with a value new for every page load), except the API reference: it's built ahead of time, with no per-load value, so its policy allows inline scripts. Pages can't be framed by other sites.

• AI provider keys, Jira tokens, repository tokens, project secrets, people's GitHub connections for merging (below) and our GitHub App key are encrypted with AES-256-GCM, under a key kept outside the database.
• The tokens Google and GitHub give for signing in are stored encrypted, and AgentMingo never hands them to a browser: the sign-in library's routes that would return them are off.
• API tokens and the connection tokens of your computers are stored only as hashes. An API token is shown once, when it's made; a computer's token never appears at all: the setup command carries a one-time code that works for 15 minutes, which the script trades for the token.
• An API token stops working when the person who made it leaves the organization or is no longer an admin.
• Passwords are stored as salted hashes. A sign-in session ends 30 days after it was last used, or when you sign out.
• Tokens and secret links are scrubbed from our logs.

AgentMingo's data lives in a Supabase Postgres database in the United States (US West). Row-level security is on for every table with no access rules, so Supabase's public API can read none of it: only AgentMingo's own servers reach the data.

• Everything belongs to an organization; people only see the organizations they're members of.
• Roles (owner, admin, member, viewer) decide who changes what. Only admins add keys and connect GitHub or Jira to the organization (anyone connects their own GitHub account, to merge from AgentMingo). Viewers read; they don't connect a computer, since a computer's threads move tasks, and they don't merge from AgentMingo.
• Everyone in an organization, viewers too, sees its members' threads: title, repository and branch, state, waits, tokens and cost, and the steps they reported.
• Images added to a task's description are told by their first bytes (the file's signature: PNG, JPEG, GIF or WebP), whatever the file is named, served only to the organization's members, viewers too, and never as a page.
• The check run AgentMingo adds to a thread's pull request when its workflow run finishes is on GitHub, for anyone who can read the repository: the task's title, the branch, what the thread reported for its build and check steps (shortened), approvers' names and comments, and tokens and cost.
• Changes to settings, keys, members and workflows, and merges made from AgentMingo, go in the organization's audit log.

The script that connects your coding agent is public: read it before you run it. It's open source: its code is at github.com/AgentMingo/reporter. It reports only threads in a repository your organization connected or you added; a thread anywhere else sends nothing about itself (only a repository named like one of your organization's has its name sent, once a day, to check whether it's that one renamed). What it sends for the others is listed, field by field, in the Privacy Policy: each thread's moments (with how long the tool call behind a working one ran) and state, its repository and branch (pushed or not, how many commits aren't, and how many files have changes not yet committed, a count only), the app, a title, what a waiting prompt asks, token counts by model, tool calls by kind with their output size and time, git commands by subcommand with their output size, edited file paths with when they were edited, its settings (review results, sharing, the lean git rules and its test group), which notes it passed on, the lookups it makes before a message and after a reply, and on a workflow the steps Claude reports (done or failed, and what it wrote) and the files it attaches. Every request but setting up and downloading an update carries the computer's connection token and the script's version. Emails, phone numbers, keys, tokens and passwords in a title are masked on your computer before it's sent, and in a step's text when it reaches us.

Install adds hooks to Claude Code's settings (~/.claude/settings.json) and keeps a copy of your settings from before. It adds five permission rules so Claude can report workflow steps and make a task's folder without asking you (the script's step and start commands and the three agentmingo MCP tools), and registers that MCP server for your user. Making a task's folder (start, or the start_task tool when you ask a thread to work on a task) copies only your clone's local .env files into it (.env, .env.local and the development and test ones), never .env.production or other .env files, which can hold production secrets that any thread in that folder could read, unless you add --env-all, which works only in your own terminal, never from Claude's own commands. A copied .env.local can still hold tokens of your own (vercel env pull writes one), so it says so when it copies one. The tool tells Claude to ask you before it moves a thread into that folder. With --lean-git, it also adds the lean git rules to your ~/.claude/CLAUDE.md, and keeps a copy of that file as it was beside it, when there was one (lean-git off takes the rules out). Uninstalling (node ~/.agentmingo/reporter.mjs uninstall) takes the hooks, the rules and the MCP server out, sets back to untrusted in Claude Code the clones its starts marked trusted (below), and disconnects the computer; it leaves ~/.agentmingo (its queue, state, log and the script) and the copy of your settings for you to delete. You can also disconnect a computer from the app at any time.

It updates itself from agentmingo.com, so what runs later can differ from what you read. A new version is used only after it's checked on your computer: in a scratch folder it must load, run, and send a test report to a stand-in for AgentMingo there. The version before is kept and runs again if the new one fails, and we can hold the computers that update at a version, or send them back to an earlier one. To turn updating off, run node ~/.agentmingo/reporter.mjs auto-update off (or add --no-auto-update to the setup command); a newer version then comes only when you run the setup command again.

Notes AgentMingo adds to a thread (a task's brief from Jira or AgentMingo, the team's rules and who set them, teammates' live threads in the same repository, review results, workflow steps) become part of that conversation, which Claude Code sends to Anthropic under the member's own plan. A teammate's threads are in the note only when both the receiving member and the teammate have sharing on: a teammate who unticked it is named in no one's notes (from reporter version 11, which computers update to by themselves). Review text and teammates' titles are framed as information to check, not as instructions, and a note you add when you deny a permission prompt here (below) as your quoted words.

With review results on, a background hook can wake an idle thread to fix what a review found, up to 3 rounds per pull request by default (each repository sets its own, 0 to 10, and a member can give a pull request more once they're used). A merge conflict on its pull request, and each step of the repository's pull request checklist, wake it too, outside those rounds. node ~/.agentmingo/reporter.mjs reviews off stops all of that. A thread that follows a workflow is also woken when its next step is ready. After each reply the hook listens up to 18 minutes for review results; in a thread that follows a workflow, and with replies from AgentMingo on (below) in any thread, up to 8 hours. It stops within seconds of you typing in the thread or the thread ending (it looks on your computer every 5 seconds), and the thread's next reply starts a watch of its own.

From reporter 18, with replies on, a thread that waits for you on work still open (its task isn't done or canceled, it has an open pull request, or its workflow run is going) is kept listening past those 8 hours, while your setting “Keep threads listening while their work is open” is on (it is by default): as a watch ends, AgentMingo's answer says whether to keep listening, and if so the hook wakes the thread with a short note asking your coding agent to reply only “Still listening for AgentMingo” and do nothing else, and that turn's end starts a fresh watch. AgentMingo's answer is only yes or no: the note's words are fixed in the reporter script on your computer (KEEP_LISTENING_NOTE), and nothing AgentMingo sends goes into it. That's about every 8 hours, for at most a week from the thread's last turn (at most 21 such turns in one wait, counted on your computer), only while your computer stays on and awake, and never in a thread whose watch hook can't give it the whole 8 hours. Each of those turns runs on your own Claude plan and re-reads the whole conversation, so it uses tokens, more the longer the conversation; the thread's page lists them with their tokens. The report of that turn's end says it was one (keepAlive), so AgentMingo starts no new turn for it and tells no one. Turning the setting off, or the work closing, stops it at the end of the watch it's in; an operator can stop it for everyone the same way.

Off unless you turn it on, on your computer: by running the setup command with its box “Answer prompts and reply to threads from AgentMingo” ticked (it is by default; the command then carries --approvals, and install says plainly what it turned on), or with node ~/.agentmingo/reporter.mjs approvals on in your own terminal (it asks you to type yes). The setup command turns it on wherever you run it, in a terminal, your editor or a coding agent's thread you paste it into, because its one-time code is your consent: it's made only for you, signed in (on the Sessions page or in the setup guide), it works once, and for 15 minutes. With an older command that carries --token instead of a code, it stays off: install still connects the computer and says how to turn it on (on already, it changes nothing). The code also carries the box's choice, and AgentMingo says it back when install trades the code: adding --approvals to a command made with the box unticked doesn't turn it on (install connects and says it stayed off), and the code can't be changed to say otherwise without breaking it. The limit: whoever runs a command made with the box ticked while its code is unused, you or the coding agent you gave it to, turns it on, as they run everything else the command does. approvals on refuses inside Claude Code's Bash tool and without a terminal. Those checks catch a command run by mistake or by your coding agent's Bash tool; a program on your computer set on faking a terminal could get past them, as it could change the reporter's settings anyway. The setup command already downloads and runs the reporter, so the box adds no trust of its own: what counts is that you run it, or give it to your agent to run. AgentMingo's website and servers can't turn it on by themselves; an update of the reporter can change anything it does, as it always could (turn updates off with auto-update off). approvals off turns it off.

• What this allows, plainly: someone signed in to your AgentMingo account can approve what your coding agent asks to run on your computer. That's you, or anyone who gets into your account, or an agent with a browser signed in as you. From reporter 17, every prompt a thread shows can be answered here, with the same answers as the terminal: commands that run on your computer, MCP and other tools, file edits anywhere (outside the repository, Claude Code's own settings, files that can run code by themselves), questions it asks you, and plans to approve. No extra check stands in the way: a signed-in session is enough. Turn it on only if that's acceptable to you, and off when you don't need it. Lost a phone, or left a browser signed in? Your account page lists where you're signed in: sign one out, or everywhere but where you are, and it has to sign in again.
• To turn it off: run node ~/.agentmingo/reporter.mjs approvals off on that computer (or run the setup command with the box unticked). Prompts are then only reported, as before, and answered in the terminal.
• When a thread started since then stops on a prompt, the prompt stays in your terminal as always, and also waits on the thread's page here (an hour unless you chose otherwise, eight at most). Whichever is answered first counts, and the other closes.
• Only you can answer it here, signed in as yourself: not teammates, not admins. Answers go only through the page, so no API token can give one. Each is tied to that one prompt (a random id, and a code your computer makes with a key that never leaves it), used once, and taken only while your computer is checking. A notice, email or push never answers anything: it links to the thread's page.
• The answers are the terminal's: Yes applies to that one call; “Yes, and don't ask again” applies Claude Code's own suggestions for that prompt, for the rest of that session only (never written to a settings file), and the card lists every rule and folder it adds (it isn't offered when one couldn't be shown exactly as it's applied); No denies it, with an optional note. A deny rule in your Claude Code settings still wins over Yes. For a file change you see its path and how many lines it adds and removes, not the change itself, and allowing a file change can still lead to running code later: tests and builds run what's in it. Badges say what a prompt is (runs a command on your computer, outside the repository, changes Claude Code settings, a file that can run code by itself, characters that don't show) before you answer. An MCP or other tool's input shows every field it carries, cut at 300 characters with a badge that says so.
• Every answer is recorded in the organization's audit log (without what it asked) and shown in the thread's history to you (“You allowed npm test from AgentMingo”), with whether your computer picked it up. For 30 days after your computer last opened a prompt here, each new sign-in to your account is emailed to you, so you'd hear of someone else's.
• What it shows is masked on your computer, best effort. A note you add to a No reaches your coding agent as your quoted words.
• Covered: every prompt in a thread's main conversation that Claude Code shares with its PermissionRequest hook. Not covered: subagents' prompts (shown as waiting, to answer in the thread), sandbox network prompts, folder-trust and MCP-server dialogs, and headless runs. A thread's page says “Answer this one in the thread” and why for those, and when it's off or the reporter is older. Only Claude Code today; the Cursor agent's hooks are ignored.
• Which Claude Code versions: Claude Code doesn't document that a hook can wait while its prompt stays usable in a terminal, so a later version could change that. The guard is the on-screen check: in a terminal the reporter waits only once Claude Code says the prompt is on screen (its notice comes about 6 seconds in), and if it hasn't said so within 20 seconds, the reporter stops waiting and leaves the prompt to the terminal alone. It waits on any version but those known to misbehave, which a reporter release lists (none so far), and its status says which. In VS Code and the desktop app, which send no such notice, Claude Code shows its prompt and runs the hook at the same time, and takes whichever answers first. If a prompt ever stops taking your keys while it waits, turn it off with approvals off and tell us.
• Between your computer checking a prompt once more before it applies your Yes and Claude Code running it, another program already running there could change what it points at (swap a file for a link elsewhere). Allow trusts what's already running on your computer.
• Your answer reaches your computer within seconds, and only while it's awake and online and Claude Code is running. An answer more than two minutes old when it arrives isn't used.
• Someone who gets write access to AgentMingo's database or servers could answer Allow for you, or show you a different file than the one that changes (or a different command than the one that runs).
• Replies: with it on, when a thread finishes its turn and waits for you, you can answer it from its page (Continue, Yes, No, or up to 1,000 characters). Only the thread's own person can send one, signed in as yourself, from the page (no API token can), and only to a computer on reporter 15 or newer that has this on, while its watcher listens (up to 8 hours after the thread's last reply, or, from reporter 18, while its work is open, a week at most: above). A reply is for the turn it answers: if you type in the thread first, the thread ends, or it goes on without it (woken for something else), it's canceled, not delivered later. Each reply is used once, expires after 2 hours, is rate limited and recorded in the organization's audit log. Your computer wakes the thread with it as your words, so your coding agent acts on it as if you had typed it. Someone who gets into your AgentMingo account could message your threads that way, and allow what they then ask to run.

Off unless you turn it on, on a Mac (reporter 19 and newer): by running the setup command with its box “Start threads on this computer from AgentMingo” ticked (ticked by default, so untick it before you create the command if you don't want it; the code carries the choice, as for answering prompts above, so adding --start-from-web to a command made with it unticked doesn't turn it on), or with node ~/.agentmingo/reporter.mjs start-from-web on in your own terminal, which asks you to type yes and refuses inside Claude Code's Bash tool and without a terminal. It installs a LaunchAgent, ~/Library/LaunchAgents/com.agentmingo.start-from-web.plist, that runs a small helper while you're logged in. AgentMingo's website and servers can't turn it on; they can only turn it off.

• Only you can start a thread on your computer: the button on a task's page works only for the person whose computer it is, signed in as themselves. Not teammates, not admins. No API token can create a start: it's a server action, on the page only.
• What AgentMingo sends your computer is a start's id and the task's key (WEB-12), nothing else: never a command, a path or shell text. Your computer checks both, asks AgentMingo for the task's branch and repository as the start command does, checks those too (a branch or a name that could be read as an option, or that leaves the folder, is refused), and builds everything else itself: the folder (a git worktree next to the clone it already knows), and one fixed command, Claude Code in that folder with the prompt “Work on WEB-12”. It opens Terminal on a file it writes itself, with only its own paths and the checked id in it.
• Claude Code's own permission settings apply as they always do: the helper never adds a permission flag, a settings file or an MCP server, and never answers a permission prompt.
• One write to Claude Code's own files, from reporter 21: nobody may be at your Mac to answer Claude Code's question whether to trust a folder, so right before it starts Claude Code for a start you pressed, the reporter marks your main clone of the task's repository as trusted: the clone itself (say ~/code/web), not the task's folder (~/code/web-WEB-12), since Claude Code keys a worktree's trust to the clone it was made from, and asks about no other folder. It sets one key, projects["<clone>"].hasTrustDialogAccepted, to true in ~/.claude.json (or the file Claude Code keeps its state in when you set CLAUDE_CONFIG_DIR or CLAUDE_CODE_CUSTOM_OAUTH_URL, or still have its older ~/.claude/.config.json), as answering yes to that question does, while it holds Claude Code's own lock on the file, and changes nothing else in the file: only that clone, only on a start, never from the hooks, the start command or install. That clone then stays trusted for every Claude Code session in it and its worktrees, on any branch, until you set the entry back to false, remove it, or uninstall. A trusted clone's own Claude Code settings apply there, as in any folder you trusted yourself: its hooks, allow rules, environment variables, helper commands (an apiKeyHelper, an MCP server's headersHelper), extra directories, and the MCP servers its .mcp.json and settings approve, from the task's branch (which may hold others' changes). Your computer tells AgentMingo the name of the repository it marked (never a path), and the task's history says so. When the file isn't there or can't be read, it writes nothing, and Claude Code asks at the computer as before. To undo it, set that entry back to false or remove it: Claude Code asks again, until a later start you press marks it again. Turning starting threads off (below) stops new marks, and leaves the clones already marked trusted (start-from-web off says which); uninstall sets each clone its starts marked back to false in the file the start marked it in, when it's still trusted. A mark you undid yourself is forgotten once a start, start-from-web off or status sees it undone; after that, uninstall leaves that clone alone.
• Limits on your computer, whatever AgentMingo says: each start is taken once (a compare-and-set here, and a marker file there), at most 6 an hour and none within 15 seconds of the last. Here: one waiting start per task per person, three per computer, 20 presses an hour, and a start nobody takes in 2 minutes expires.
• Every start is told: a notice to you naming the computer and the task, a line in the task's history, and the organization's audit log.
• Two off switches: node ~/.agentmingo/reporter.mjs start-from-web off on the computer (it stops the helper and deletes the LaunchAgent, for every organization there), or Turn off on your Account page, one organization at a time: it cancels starts waiting from that organization, and at its next check the helper stops taking them. A computer connected to more than one organization keeps taking the others' starts until each is turned off; with none left, its helper stops. Turning it on again needs the computer. uninstall removes it too. Neither off switch unmarks a clone a start marked trusted (above); uninstall does.
• What remains: someone who gets into your AgentMingo account can open a thread on your Mac on one of your organization's tasks, and, if answering prompts from AgentMingo is on there, answer what it then asks to run. Turn it on only if that's acceptable to you.

• The GitHub App works only on the repositories you choose, and every webhook GitHub sends is checked against its signature.
• The App asks to write code, pull requests, checks and issues, and to read statuses and deployments. AgentMingo writes a check run with the run's report when a thread's workflow run finishes (anyone who can read the repository sees it; what it shows is above), and an issue when someone exports a task to GitHub Issues. Writing code and pull requests with the App's own access is for AgentMingo's own agents, which aren't on at agentmingo.com yet: they push only in a run a person started or a workflow an admin set up, and merge a pull request only when that workflow says to.
• Merging from AgentMingo: a member (not a viewer) can merge an open pull request from its thread's page or its task's page. It merges as them: they connect their own GitHub account once (they authorize AgentMingo's GitHub App on GitHub), and AgentMingo merges with that authorization, never with the App's own access. GitHub checks their permission and the branch's rules, and shows them as the one who merged. Nothing merges by itself: AgentMingo first asks GitHub whether it merges, shows the base branch it merges into and the head commit, and merges only that commit, only when they choose Merge (GitHub refuses it if another commit lands first, and if the pull request was moved to another base branch since, it shows them the new one instead of merging). It deletes the branch only if they tick that, and never one another open pull request builds on or merges from. Merges are limited to 30 an hour per person and recorded in the organization's audit log as soon as GitHub confirms them; a merge GitHub didn't confirm in time is recorded as unconfirmed.
• The GitHub tokens for merging are encrypted, never sent to a browser, used only when their person chooses Merge (to ask GitHub whether it merges, merge it, and delete its branch if they ticked that), and deleted when they disconnect on their Account page (AgentMingo also asks GitHub to revoke the access token) or GitHub stops accepting them. What they make possible: they act on GitHub as that person, within both what the App may do (write code, pull requests, checks and issues, read statuses and deployments, and read the email addresses on their GitHub account) and what their own GitHub account may do, on the repositories the App is installed on. So someone who gets into their AgentMingo account could merge what they can merge (through the same confirm step), and someone with AgentMingo's database and its encryption key could act as them that way until the tokens are revoked or run out (a refresh token lasts 6 months). Revoking AgentMingo's App in your GitHub settings ends them too.
• An installation of the App is connected to your organization only once GitHub confirms it's yours: your GitHub account is the one it's installed on, or the one that installed it on a GitHub organization (or asked an owner to). Being able to read one of its repositories, or adding one to it, isn't enough.
• Review results and checks reach your threads only from your repositories' own pull requests, never from a fork's, whatever its branch is called. A check counts as your main branch's only on commits pushed there.
• AgentMingo writes to Jira only when an admin turns on moving issues along with the work, or when someone exports a task to Jira.
• You can remove either connection at any time.

Email hello@agentmingo.com with what you found and how to reproduce it. We'll confirm we got it and keep you posted until it's fixed. The same address is in /.well-known/security.txt.

Please don't access or change other people's data, disrupt the service, or make the issue public before it's fixed. If you follow that and act in good faith, we won't take action against you for your research.

How we handle personal data is in the Privacy Policy.