Security and data

In short

• imece does not upload the contents of your repo files to a server.
• What you share with the team passes through our servers and is stored there: decisions, notes, handoffs, messages and files you attach in chat.
• The servers are in Germany (Hetzner). Requests pass through Cloudflare's network.
• The server can read this content. There is no end-to-end encryption.
• Notes with personal scope are not sent to the server.
• When a member is removed from a team, their access closes within a few minutes. The copies on their computer are not deleted.
• The relay keeps the last 72 hours. The archive has no automatic deletion. For deletion requests, write to hello@imece.io.

How imece worksPrivacy

Where your data lives

Our servers are in Germany, at Hetzner. Requests pass through Cloudflare's network. Data lives in these places:

• Your computer: the ~/.imece folder (on Windows, %USERPROFILE%\.imece). The local database inside holds your copy of the team's records, including the ones that came from teammates. imece does not encrypt this database. The folder also carries your relay token, so don't share it. In the repos you selected there is also an .imece/ folder with summaries; imece keeps it out of git.
• Your teammates' computers: a copy of the records you send is kept there too.
• The relay: your team's live delivery service. Each team's relay runs in its own namespace and on its own disk. It keeps events for the last 72 hours.
• The archive: the permanent record of the events that pass through the relay. Each team has its own disk. A new device or member gets history back from here; the relay only returns the records that person is allowed to see.
• The account server: shared by all teams. It holds account details, team and project memberships, files attached in chat and security logs. If you sign in with GitHub, we store only your GitHub account ID (a number).

What goes to the server

Hooks talk only to the daemon on your computer. The daemon (imece's background service) sends the following to the relay or the account server. You or your agent write most of the content.

• Team records: decisions, notes, abandoned approaches and open work. Your agent can write them without asking you. Records whose scope is not personal go to the team.
• Handoffs: title, what, why and context text.
• Channel messages, reactions and direct messages (DMs). A DM is delivered only to its recipients.
• Files and images: a file you attach in chat is uploaded to the account server. The message carries only the file's name, size, type and ID.
• Project ID: the origin address of the repo you added, in the form github.com/company/repo. The user name and password are dropped. If there is no origin, a hash of the path is used.
• Work state: project, branch name and topic. The topic is the branch name; sometimes it is the common parent folder of the files you touched or the title of your last team note. Whether your agent is active or idle is sent too. Durations and file names are not sent.
• Member details: your name, role, device ID, your computer's name, the imece version, the names of the installed hooks and your profile photo if you set one.
• Connection details: your IP address reaches the servers you connect to and Cloudflare. The privacy notice has the details.

Privacy

What stays off the server

• The contents of your repo files, diffs and git history. imece does not upload the repo. If you write a code snippet or a file path into a text, that text is team content and goes to the server.
• File names. The conflict warning runs on your computer: it compares the files you changed with your teammate's branch locally, using git. imece takes only the branch name and topic from your teammate; git works out the file list from the repo on your computer.
• What hooks read locally: imece's hooks read the names of changed files and the changed line counts and write them to the local database (not the diff content). That list is not sent to the server.
• Your prompt text. imece's hooks pass your prompt only to the daemon on your computer. The daemon handles it locally; it is written neither to the database nor to the relay. A note or handoff your agent writes on your behalf is separate: that is team content.
• Your agent's last message. imece's hooks read it locally and check whether work that belongs to another role came up. The text is not stored; only the matching keyword is recorded locally.
• Notes with personal scope: they are not put in the send queue and stay on your computer.
• Your GitHub connection: the token of the account you connect for “Pick from GitHub” in the desktop app sits in your operating system's keychain (Windows Credential Manager, macOS Keychain). It is not sent to imece's servers, only to GitHub.
• DMs: hooks do not add DMs to your agent's context, and MCP tools do not search them.
• Repos you did not select: imece works only in the projects you added. In any other repo imece does not run.

See and turn off work state

Work state is the data that tells the team the most: project, branch name and topic. To see what is sent, run imece doctor. The line that starts with çalışma yayını (the command-line output is in Turkish) shows whether sharing is on or off, and the last branch and topic published.

To turn it off, add "share_work_state": false to the daemon section of ~/.imece/config.json. The setting takes effect when the daemon next starts: stop it with imece daemon --stop, and the next imece command starts it again.

While it is off, the project, branch and topic announcement and your agent's active or idle state are not sent. Only your own broadcast goes quiet; you still see your team's state.

Who can read it

Your teammates read the records they are allowed to see. The server can read them too. The details:

• Team members: project records are delivered to the members assigned to that project. A DM is delivered only to the two sides of the conversation.
• The server: the relay and the archive keep messages, notes and handoffs readable; files sit on the account server's disk. The imece team, with access to the servers, can technically read this content. We handle deletion and export requests by hand. This is an access boundary, not encryption. Don't write passwords, tokens or secret keys into imece.
• Encryption: there is no end-to-end encryption. imece does not encrypt the local database either. If you lose a device, the copy on it is readable; we recommend encrypting the disk (FileVault on macOS, BitLocker on Windows).
• In transit: your team's relay address starts with https://. Traffic between your computer and the server is encrypted with TLS and passes through Cloudflare's network. Inside the server cluster's own network, connections between applications use plain HTTP.
• Your agent's provider: team content that enters your agent's context through the hook also reaches the model provider that runs that agent (such as Anthropic or OpenAI). The provider handles it under its own terms; that is outside imece.
• Other processes on your computer: imece does not protect against processes running as the same user, including your agent. They can read the ~/.imece folder and the GitHub token in the keychain. The daemon's local API listens only on 127.0.0.1 and requires a token, but that token sits in the same folder.

How access is controlled

• Each member has their own token. imece renews it automatically.
• Identity comes from the token: the relay checks that the sender of an event is the member named in the token. It rejects an event sent in another member's name.
• Removing a member: a team admin can close a member's access, and a member can leave on their own. A closed member cannot get a new token. The relay picks this up within a few minutes; then the member's open connection closes and their token is rejected. So closing takes effect within a few minutes, not instantly. If the account server is unreachable, the relay keeps working with the last list it has.
• The copies already on the member's computer are not deleted. There is no remote delete command.
• Project visibility: a team admin decides which projects each member sees. On teams set up through the account server, the relay applies that list: events from a project you are not assigned to are not delivered to you, and you cannot write events to that project. History a new device gets back from the archive follows the same rule.

Limits of project visibility

• The list reaches the relay every few minutes. After you remove a member from a project, they can keep receiving new events for a few minutes.
• Events that reached a member's computer before they were removed are not deleted.
• Team-wide events go to everyone: member announcements and the general channel. Because a member announcement also carries work state, a member who is not assigned to a project can see the work state (project address, branch, topic) of someone working in it. Use the setting above to turn it off.
• If the relay has not received the membership list yet (for example it just started and the account server is down), project-scoped events are held back; they are not sent to everyone.

How long data is kept

• On your computer: imece does not clean the local database by itself. It stays until you delete it.
• The relay: the last 72 hours. Old events drop out on their own.
• The archive: no automatic deletion. As the privacy notice says, team content stays for as long as the team account is open.
• Files: until you or a team admin delete them. If you delete a channel message, its attachment is deleted too.
• Security logs: 90 days.
• Account database backups: kept for 7 days.

Deleting: what it does and does not do

Send a deletion request to hello@imece.io from the email address linked to your account. As the privacy notice says, we reply within 30 days. During the closed beta we handle requests by hand.

• Delete a channel message: only its author can delete it. The message shows as deleted in your teammates' app, its attachment, if any, is deleted from the server, and its body in the archive is blacked out shortly after. It can stay in the relay's 72-hour buffer until it ages out.
• Delete for me on a DM: the message disappears from your view only. The other person's copy and the archive copy stay. There is no delete for everyone.
• Withdraw a note from the team: use the Remove from team button in the desktop app, or imece scope <record ID> personal; the copy stays with you as personal. To hide it from your own view too, use imece forget <record ID>. In both cases the note disappears from your teammates' app; its original version stays in the archive.
• What we do on request: delete your account details and black out the content of the events you sent in the archive.
• What we cannot do: the copies on your teammates' computers, DMs other people sent you, and your name where it appears in other people's messages. Deleted data can stay in account database backups for up to 7 more days.
• You delete the local copy: if the command-line tool is installed, remove the hook and MCP entries with imece setup claude-code --uninstall (--dry-run first shows what would change), then delete the ~/.imece folder.

Privacy

Team content and prompt injection

Text written by a teammate (or by a compromised account) enters your agent's context through the hook. imece marks that text as data, not instructions. This reduces the risk; it is not a promise. imece cannot decide whether a model will follow an instruction inside the text. Keep your agent's permission settings tight.

Report a security issue

If you found a security issue, write to hello@imece.io and add “Security” to the subject line. Tell us what you saw, at which address or version, and the steps to reproduce it. Don't access more data than you need to show the issue, and don't share the finding publicly until we have fixed it.