Contact

The fastest route depends on what it is about. A crash, a vulnerability and a partnership question need three different doors, and putting all three through one address slows all three down. There is no form on this page — find the row below that matches what you have, and go straight there.

Last updated 19 August 2026

If you have found a vulnerability, do not open a public issue. A GitHub issue is public from the moment you submit it, so filing one is the disclosure. Use the private channel described in the security policy instead. Everything else on this page belongs in the open, and is better there.

Where to send it

A bug, a crash, or an answer that is wrong: GitHub issues. That covers a caller it missed, a test file it should have found, a file it failed to parse, a tool that returned nothing where something exists, and a crash. A wrong or incomplete answer is a correctness bug, not a security bug — it goes here, in public, where the fix can be checked. The list further down is what saves a round trip.
A security vulnerability: The security policy, which routes to a private GitHub advisory. Do not file it as a public issue. The advisory thread stays private until an advisory is published. Response is best-effort rather than contractual — there is no staffed security team — and in practice an acknowledgement often comes within a few days, though nothing here sets a response time. A valid report is worked on and, where it warrants one, an advisory is published crediting you unless you ask it not to. That is best-effort too: no committed timeline, and no guarantee that any particular report is fixed. A report judged not to be a vulnerability gets told so, with the reasoning. What counts as which is below.
A feature request, or a language that resolves badly: GitHub issues, the same tracker. Sixteen languages parse in the shipped version — the repository README lists them and names which of the three parsing strategies each one goes through. Call-graph resolution is strongest in TypeScript and thinner elsewhere, and that gap is known rather than hidden. If yours resolves badly, a small snippet the graph got wrong is worth more than a description of it.
Early access to the hosted product: The form on the home page. Euthynos for teams is not open yet — there is no instance to log into today, and nothing here commits to there ever being one. The form asks for an email address plus three optional questions: which agent you use, your team size, and what you would want it to catch. Two further values are stored that you do not type — the page that referred you, and a salted hash of your IP address — and what this site records sets out both, with the privacy notice as the full account. The address is used for a single email if and when it opens, and for nothing else, ever: no other mail before it and none after. There is no date. It is not a purchase, and there is no payment path anywhere on this site.
Anything else, including press and partnerships: [email protected]. This is also the address for licensing questions, for use of the name or the logo, and for anything that does not belong in a public tracker. It is read, not staffed — what that means in practice is below.
Following along: @EuthynosDev on X, and the RSS feed, which carries each post in full rather than an extract. Watching the repository on GitHub is the highest-signal option, because the release tags and the changelog live there. There is no newsletter, and no mailing list other than the early-access one.

What this site records when you get in touch

Most of the routes above are not run here at all. An issue or a private advisory lives on GitHub, under GitHub’s terms and subject to whatever GitHub logs; an email passes through whatever handles the mailbox at each end. Only the early-access form runs on this site, so it is the only one this page can account for directly.

What you type is stored: the email address, and any of the three optional answers you filled in. Three more values are stored that you did not type. The first is your browser’s referrer — the page that linked you here — cut to 300 characters by the browser and capped again at 400 by the server. The second is a salted SHA-256 hash of your IP address, truncated to 32 hexadecimal characters, used to cap signups at five per hash per hour; the raw address is not written into the row. The third is the row’s own number and the time it was written. The form also carries a field hidden from people that automated submitters tend to fill in. A submission that fills it gets an ordinary success response and is stored nowhere.

The salt fails closed. The handler reads IP_SALT, falls back to SESSION_SECRET, and if neither is set to at least sixteen characters it refuses the request with a 503 and stores nothing at all. There is no built-in default, because a salt committed to a repository is public, and a public salt makes a hash of an IPv4 address reversible by brute force in seconds — which would make the protection cosmetic.

The endpoint returns the same body for an address it has never seen and one it already holds, and the page shows one message either way. That is deliberate. An answer that distinguished the two would let anyone test an address and learn from the reply whether its owner had signed up, so the endpoint returns no stored information to an unauthenticated caller.

Above the application sits the serving chain, and it sees things the application never touches. euthynos.dev is served by Cloudflare in front of Vercel, and both companies are in the request path. Cloudflare terminates TLS, so it is the first to receive your IP address, user agent, the URL you asked for and the timestamp — before Vercel, and before any code written here. Vercel’s edge sees the request after that. Cloudflare’s edge also sends Network Error Logging directives, which instruct your browser to report failed requests to a.nel.cloudflare.com; that report is generated by your browser rather than by anything on this site, and it goes to Cloudflare. Typing www.euthynos.dev adds one more request Cloudflare sees, because www redirects to the bare domain. Both companies keep their own logs under their own terms. “Nothing is collected” would be false at that level; what is true is narrower, and it is the only thing this page claims: the application code stores the row described above and nothing else.

Security, and what counts as security

The dividing line matters, because treating a correctness bug as a vulnerability delays the reports that are one. Euthynos is a static analyser that reads your repository; the things that can go genuinely wrong are about what it reaches and what it runs, not about whether an answer was complete.

Behaviour	Treated as
Escape from the servable roots, or a read of a file outside the repository	Security — private advisory
A symlink followed out of the root	Security — private advisory
Code execution triggered by the contents of a repository being scanned	Security — private advisory
A network request from the query path	Security — private advisory
The server disclosing a file it was not asked for	Security — private advisory
A wrong, missing or incomplete answer	Correctness bug — public issue

One deliberate exception to the network row: euthynos scan --ai sends up to eight candidate duplicate pairs to the Anthropic API — each pair being the two source snippets, up to 60 lines each, together with their file paths, line numbers and function names. It is opt-in, off by default, requires ANTHROPIC_API_KEY, and is not part of the MCP server. Traffic from that flag is the documented behaviour of that flag, not a finding.

One thing that is written but not sent, so that you are not surprised to find it: the MCP server appends a line of call metadata to a file under .euthynos — the tool name, response size, timing, cache hit or miss, and a hash of the arguments rather than their values. No source code goes into it. The module that writes it appends to disk and contains no network calls at all, which is why the site says no telemetry is sent anywhere rather than claiming none exists. The file is yours to read and yours to delete.

What to expect back

Euthynos is maintained by one person alongside other work. That is the whole staffing picture, and what follows describes how it has gone rather than setting a schedule:

Security reports: the security policy says to expect an acknowledgement within a few days. Best-effort, not contractual.
Issues: read when they are read, usually within a week or two. Nothing schedules this. Triage and a fix are two different clocks — a confirmed bug can sit longer before it is fixed, and it will say so on the thread.
Email: slower than the tracker, and sometimes much slower. There is no monitored-inbox commitment behind this address.
Early access: one email if and when it opens, and nothing before it. There is no committed launch date, no drip sequence to wait for, and nothing here commits to it opening at all.

Silence is not a rejection. If a thread goes quiet, a comment on it is a reasonable nudge and is the fastest way back onto the list. None of the above is a service-level agreement, and none of it is backed by a support contract — if you need a guaranteed response time, this project has none to offer you today.

Before you write

A bug report that carries these five things can usually be reproduced without a reply. One that does not costs a round trip before anything starts.

The version. npm ls -g euthynos prints the installed version, and euthynos index --status prints the index schema version with the engine build stamp beside it, which is the more precise pair. There is no --version flag today, and --help prints usage with no build stamp in it — the issue template and the security policy both say otherwise, and on that point they are wrong.
The agent, and how it is wired. Claude Code, Cursor, Codex, Windsurf or something else — and whether the failure came through the MCP server or the CLI. The two paths differ.
The language, and roughly the repository size. File count matters: validation runs to about 10,000 files, and behaviour above that is unmeasured rather than guaranteed.
The exact tool call and its arguments, plus the output you got, pasted verbatim. Many answers carry a scope or boundary line naming what was not examined — if yours has one, include it, because it is often where the explanation is.
What you expected versus what happened. Name the symbol, file and line you expected to see. “It missed a caller” is a lead; “it did not list setCookie at src/helper/cookie/index.ts:99” is a test case.

Worth checking first: whether it survives euthynos index --rebuild. The index is derived state and can be deleted at any time, so a stale index is one of the cheaper explanations to rule out. If a rebuild fixes it, that is still a bug worth filing — it just changes what the bug is.

What this costs

Nothing. The command-line tool is free, runs locally, and is licensed under Apache 2.0 — the licence, not a trial period, and it is irrevocable for every release it covers. No account and no credit card, and no key for anything in the query path. The one exception is the opt-in scan --ai flag described above, which needs your own ANTHROPIC_API_KEY — an Anthropic key you already hold, not one issued here.

There is no paid support tier today. No priority queue, no support contract, no paid triage, and nothing that moves a report up the list. Everyone is in the same queue, and the queue is the one described above. Contributions are welcome and use DCO sign-off — a one-line certification added to each commit, with the text you are certifying kept in the repository. There is no contributor licence agreement to sign, and the contributing guide says there will not be one.

Euthynos is maintained by Tonil Kumar as an individual. There is no company behind it, and nothing on this page should be read as implying one. The name and the logo are claimed as unregistered marks — used and claimed, not registered — and anything you are unsure about goes to the address above.