How do you check a coding tool an AI assistant recommended?

Short answer: run four checks that take about a minute together, and run them against the address the assistant gave you, never against the name it used. Does the link still respond, is the repository behind it the one that was actually cited, is that repository still being worked on, and does the tool's own page say what it is without JavaScript. We ran these on every link two AI assistants gave us on August 10, 2026: one of the twenty addresses does not resolve at all, and for one of the names, searching GitHub returns a different project than the one the assistant linked to, with 37 times more stars.

The starting rule is the one that cost us the most. When we first ran this, we took the tool names out of the answers and looked each name up. That produced three wrong identifications in a row, because a name is not an address: the same name can belong to a dead domain, to a different product on another top level domain, and to two separate repositories. Everything below therefore begins with the URL the model printed. Every number here was measured on August 13, 2026 with the commands shown, in plain POSIX shell with curl and grep.

What do the four checks look at, and how long do they take?

The four checks answer four different questions about a recommended tool, and none of them needs an account, a token or a paid API. The first asks whether the address the assistant printed still responds, which is the cheapest possible test and the one people skip. The second asks whether the repository behind that address is the one you would have found by searching for the tool's name, because when those two differ, everything you conclude afterwards is about the wrong project. The third asks whether the code is still being touched. The fourth asks whether the tool's own page explains what the tool is in the HTML it serves, without a browser running JavaScript.

Together they take about a minute per tool, and they are deliberately cheap because the point is to run them on every name in the answer, not only on the one you already liked. None of the four is a verdict on quality, and a tool can fail one of them for perfectly good reasons. What the four produce is a profile: a live address, a repository that matches the link, recent commits and a page that describes itself is a very different object from an address that times out, and knowing which one you are about to install is worth sixty seconds.

Does the address the assistant gave you still respond?

The first check asks nothing more than whether the link is alive, and it is one command with no parsing:

curl -sL -m 12 -o /dev/null -w "%{http_code}\n" "https://getclaudia.org/docs/features/project-session-management/"

On August 13, 2026 that returned 000, which is what curl reports when there is no connection at all. That address was cited by one of the assistants as the documentation of a tool it recommended for managing Claude Code sessions, and the domain does not resolve. Running the identical command against another cited link, the repository https://github.com/hex/claude-sessions, returned 200.

A dead link is not proof that a tool never existed, and domains lapse for ordinary reasons. What it does prove is that whatever the model knows about that tool, it is not reading it from that page today, and neither can you. This check matters more than it looks because of what it protects against: if you skip it and go looking for the tool by name instead, you will find something, and what you find may be a different product with a similar name on a different top level domain. That is exactly the mistake we made in the first version of this article.

Is the repository with that name the one the assistant actually linked?

The second check compares what a name search returns against what was cited. Ask GitHub for repositories with the name, ordered by stars:

curl -s "https://api.github.com/search/repositories?q=claude-sessions+in:name&sort=stars&order=desc&per_page=3" | grep -o '"full_name": "[^"]*"'

On August 13, 2026 that printed, in order, iannuttall/claude-sessions, wbelk/claude-qmd-sessions and hex/claude-sessions. The repository the assistant actually linked is the third one, hex/claude-sessions, with 33 stars. The first result, which is what you get if you search by name and stop at the top hit, has 1211 stars, which is 37 times more, and is a different project by a different author.

This is the check that turns a name into an object you can inspect. Star count is what ranks that search, so searching by name systematically hands you the most popular project sharing the name rather than the one that was recommended to you. If the assistant gave you a link, the link is the answer and the search is only a way to discover that other things share the name. If the assistant gave you a bare name and no link, then this check is where you learn that you cannot resolve it confidently, and the honest move is to ask the assistant for the URL rather than guess.

Is the project still being worked on?

The third check reads three fields from the repository that the link identified:

curl -s "https://api.github.com/repos/hex/claude-sessions" | grep -E '"(created_at|pushed_at|stargazers_count)"'

On August 13, 2026 that printed:

  "created_at": "2025-11-24T08:19:11Z",
  "pushed_at": "2026-08-13T17:54:03Z",
  "stargazers_count": 33,

That is a small project that received code on the same day we checked. Run the identical command against the popular namesake, iannuttall/claude-sessions, and it returns a creation time of 14:39:53 on June 16, 2025, a last push of 14:50:30 on that same day, eleven minutes later, and 1211 stars. It has not been touched since. A third cited repository, kbwo/ccmanager, returns 1218 stars with a last push on August 10, 2026.

Stars measure attention at some point in the past, and pushed_at measures whether anyone has touched the code recently. The pair of namesakes above is the clearest possible demonstration that the two numbers can point in opposite directions: 33 stars and active, against 1211 stars and frozen since eleven minutes after creation. An assistant's answer carries neither number, so a tool that stopped in 2025 arrives in the same sentence, with the same confidence, as one shipping today.

Does the tool's own page say what it is without JavaScript?

The fourth check downloads the tool's page the way a script or a crawler would, with no browser and no JavaScript engine, and asks how much came back:

curl -sL -o /dev/null -w "%{size_download}\n" "https://claude-handler.com/"

On August 13, 2026 that returned 16892, and the meta description inside that HTML says in one sentence that it is a terminal session manager for Claude Code that runs multiple instances and switches between projects. The same command returns 146631 for nimbalyst.com and 69835 for dispatch.codes, and both of those also describe the product in one sentence in the HTML they serve.

A small page is not a defect and a single page application is a normal engineering choice, so this check is not about a site being bad. It is about what is available to something that does not run JavaScript, which includes most crawlers, many link previewers, and you when you are checking quickly from a terminal. Honesty about our own result: among the tool sites cited to us, this check failed nobody. Every site that responded also described itself in its HTML, which is worth reporting precisely because it is the opposite of what we expected to find when we wrote the check.

Has anyone besides the author discussed the tool in public?

There is one more question worth asking, outside the four, for when the four leave you undecided: whether anyone other than the author has discussed the tool in public. Hacker News is the cheapest surface to query for that. There is one trap in the response: the first field named nbHits in the JSON belongs to an exhaustive object and holds a boolean, not the count. Filtering for a line that begins with the field name avoids it:

curl -s "https://hn.algolia.com/api/v1/search?query=dispatch.codes" | tr ',' '\n' | grep '^"nbHits"'

Read the result as a presence test, not as a measurement, and here is why, measured on ourselves. The total for one recommended name was 34 when we ran it early in the evening of August 13, 2026 and 47 about an hour later, while five consecutive calls in the same minute returned the identical number every time. The count is stable within a burst and moves over hours, so publishing it as a fixed figure would be dishonest, and a reader pasting the command tomorrow should expect a different number. That instability is also why this question sits outside the four rather than among them.

The count also does not separate homonyms: the matches for one recommended tool include a radio hardware project created in 2013 with no relation to AI coding agents. So treat a high number as "worth opening the results" and a zero as the more definite signal, because zero means no story and no comment on that surface has ever contained the string. One of the tool addresses cited to us returned exactly that, zero.

What did the four checks return across every link two assistants gave us?

The material came from our own measurement rather than a list we chose. On August 10, 2026 we put eleven questions about running several AI coding agents to two assistants, Claude and Codex, without naming our product in any prompt, and kept all 22 answers. Seven of the 22 contain at least one URL, with 36 URLs in total and 20 distinct ones. That is the whole evidence base, and it is small enough to check by hand, which is the point.

Sorting the 20 distinct addresses by what they are: nine are official documentation or announcements from the companies that make the agents, at code.claude.com, developers.openai.com, learn.chatgpt.com, docs.cursor.com and openai.com; four are GitHub repositories; five are the home pages of tools; and two are blog posts. Checked on August 13, 2026, eighteen of the twenty return 200, one returns 403 to a client without a browser, and one does not resolve at all. Among the tool names in those answers, exactly one appears in awesome-claude-code, a widely referenced curated list of the category whose README was 140813 bytes when we read it. And our own product appears in zero of the 22 answers, which is the least flattering number in this article and the reason we trust the rest of it.

Does a poor result on these checks mean the tool is bad?

No, and treating the four checks as a score is the main way to misuse them. A closed source product has no repository to inspect, and that is a business model rather than a warning. A page rendered entirely in the browser is a common architecture. A quiet Hacker News count can simply mean the audience lives on Reddit, on Discord or inside a company. Each check answers one narrow question, and the four together describe how much public evidence exists about a tool right now, not how well it works.

What the checks do rule out is the specific failure they were built for: installing something because a model listed it next to names you recognised, and only afterwards discovering that the link is dead, or that the repository you read was a namesake with different code in it. The honest use is to run all four on every name in the answer, including the ones you like, and then decide with the profiles side by side. If a tool you want to use comes out poorly on three of four, that is not a reason to reject it, it is a reason to ask its maintainer a direct question before you depend on it.

Why does this matter more with an AI answer than with a page of search results?

A page of search results carries signals you read without noticing: the domain, the date, the snippet, how many results the query returns, whether the top links come from places you already trust. An assistant's answer strips all of that away and hands you a clean list of names inside a confident sentence. The names arrive with equal weight, and nothing on screen separates a project shipping code today from a domain that stopped resolving.

Our own measurement makes the point concretely. Twenty distinct addresses came out of 22 answers on August 10, 2026. Three days later one of those addresses did not resolve, and for one tool name, the repository a name search puts first is not the repository that was cited and has 37 times the stars of the one that was. Neither fact is visible in the answer, both are visible in about a minute of curl, and the gap between those two statements is the entire reason this method exists.

How is this different from comparing the tools themselves?

This article is about verifying a recommendation, not about choosing between products. We publish a separate comparison of the tools in this category, including where competitors do things better than CanvasCode does, and that one answers "which should I use". This one answers the question that comes before it: whether the thing you were just told to use is a project you can actually inspect today. The two do not overlap, and you can run these four checks on every tool in that comparison, ours included.

CanvasCode is a macOS app for running several AI coding agents on one canvas, and it fails the second and third checks by design, because it has no public repository to inspect. That is exactly why the method matters more than any single result: a check a tool fails tells you which question to ask next, not that the tool is disqualified. Run the four against the address you were given, write down what each one returned, and then decide with that evidence in front of you instead of the confidence of a sentence that came out of a model. We wrote the first version of this article by looking up names instead of addresses, and the four checks are what caught us.