DEV Community: Anand Prakash Srivastava

My first cognee connector: syncing Basecamp into an AI agent's memory

Anand Prakash Srivastava — Sat, 31 Oct 2026 12:24:51 +0000

Basecamp is where a lot of small teams keep the boring but important stuff. The message that says when something launches. The to-do list of what is left. The comment under it saying "this needs a security review first". It is all there, just spread across a project in a way that is easy to lose track of.

Basecamp was the first connector I built for Mergetober. It syncs messages, to-dos, documents and comments into cognee, an open source memory layer for AI agents, so you can ask questions about a project instead of clicking through it. It is PR #352 in cognee-community, for issue #4707.

How I use it

I set up a small product launch across three tools to try my connectors together: discussion in Twist, tasks in Basecamp, the customer email in Mailchimp. (The Twist and Mailchimp connectors have their own posts.) Basecamp holds the "what is left to do" side.

My project has a "Q4 launch plan" message, a "Launch tasks" to-do list with "Write release notes" and "Fix login bug", and a couple of comments. Each item becomes one document. These are from my live sync:

# Q4 launch plan

Basecamp Message
Project: My Project
Author: Anand
Created: 2026-10-08

We will launch the mobile app on Nov 22. The payments team owns checkout.

# Comment on message "Q4 launch plan"

Basecamp Comment
Project: My Project
Author: Anand
Created: 2026-10-08
On message: "Q4 launch plan"

Checkout needs a security review first.

# Write release notes

Basecamp To-do
Project: My Project
Author: Anand
Created: 2026-10-08
To-do list: Launch tasks
Completed: yes
Due: 2026-10-09

Include the Q4 changes.

Two small things there took me a while to get right. A comment on its own ("Checkout needs a security review first.") means nothing, so every comment carries its parent's title. And a to-do carries its list, whether it is done, and its due date, because "which to-dos are done?" is one of the first things you ask.

The code to sync and ask:

import cognee
from cognee_community_connector_basecamp import basecamp_source

await cognee.remember(
    basecamp_source(
        "1234567",  # your account id
        access_token=token,
        user_agent="My Sync (me@example.com)",  # Basecamp requires one
    ),
    dataset_name="basecamp",
    write_disposition="merge",
    max_rows_per_table=0,
)
print(await cognee.recall("Which to-dos in Launch tasks are completed?", datasets=["basecamp"]))

On my account, with Gemini as the LLM and local embeddings, I got:

Question	Answer from cognee
When is the mobile app launching?	"The mobile app will launch on Nov 22."
Which to-dos in Launch tasks are completed?	"'Write release notes' and 'Fix login bug' are completed."
What did people say about checkout?	"Anand said that checkout needs a security review first and that the payments team owns it."

The first answer says Nov 22 because I had just edited the message from "Nov 15" to "Nov 22" and synced again. The old date was gone from memory, which was exactly the test.

How it works

One endpoint for everything

Basecamp's API is organised by project and tool. You can walk projects, then message boards, then messages, then comments, and so on. That is a lot of requests. But there is one endpoint that lists everything of a given type across the account:

GET /projects/recordings.json?type=Message&status=active&sort=updated_at&direction=desc

It takes type (Message, Todo, Document, Comment), status (active, archived, trashed), an optional bucket to limit it to some projects, and sorts newest first. The whole connector reads from this one endpoint. Paging follows only the Link: rel="next" header, never page numbers I make up myself.

Two ways to avoid doing work

ETags. The first page of each listing comes back with an ETag. Next run, I send it back as If-None-Match. If nothing changed, Basecamp answers 304 Not Modified with no body. Since any change bumps an item's updated_at and moves it to the top of a newest-first list, an unchanged first page really does mean nothing changed for that type.

An updated_at cursor. If something did change, I read from the top and stop as soon as I reach items older than the last run's newest timestamp (minus a five minute overlap, so a clock difference cannot make me miss something):

for rec in client.list_recordings(record_type, status=status, project_ids=config.project_ids, etag=etag):
    updated = _parse_ts(rec.get("updated_at"))
    if stop_before and updated and updated < stop_before:
        break
    ...
    yield row

Both live in dlt's resource state, which is only saved when the load succeeds. A run that fails halfway leaves the state where it was, and the next run starts from the same point.

Deletes are where it gets interesting

There are three ways an item can leave a project, and they need three different answers:

Trashed is easy. The item moves to status=trashed and its updated_at moves, so the next incremental run finds it in the trashed listing and yields a _deleted row. dlt removes the row and cognee forgets it.

Archived is not a delete. I checked live: the item moves to status=archived and its comments follow it. Nothing was lost, so archived items stay in memory, marked "Status: archived".

Purged is the hard one. When the trash is emptied, either by hand or automatically after 25 days, the item vanishes from every listing and a GET returns 404. There is nothing left to see in an incremental run. So every 10th run (or with full_sync=True) the connector does a full sweep: it lists everything that is active or archived, and anything it synced before that is not in that list was purged.

These are my live runs on the account:

Step	Change in Basecamp	Result in cognee
0	Baseline	Full sync, 5 documents
1	Edited a message ("Nov 15" to "Nov 22")	Only the changed item re-read; new text stored, old text gone
2	Completed a to-do	Stored as "Completed: yes", still in memory
3	Created a to-do	Added (6 documents)
4	Trashed that to-do	1 deletion, the other 5 unchanged

The bug I shipped in the first version

The sweep had a problem that I only saw after the reviewer on my Twist PR found the same pattern there. My sweep forgot every synced item that it did not see. Now think about what a sweep looks like when you pass a wrong project id, or the token loses access to a project, or the API returns something odd that parses as an empty list. It sees nothing. So it forgets everything.

I wrote a test for it on the old code: 12 synced items, a sweep with a wrong project filter, and 12 of 12 forgotten in one run. That is the whole dataset gone because of a typo.

Now:

If a sweep finds more than half of what it synced newly gone, and at least 10 items, it holds those deletes back and reports them as held_back. The very next run sweeps again (it does not wait for the 10th run), forgets the held items that are still gone, and keeps the ones that came back.
Items in the trash are never held. The trashed listing is direct evidence that the user deleted them.
A listing page that is not a JSON list, or a next link that points back at the same page, stops the run with an error instead of being read as "nothing here".

if not isinstance(items, list):
    # An odd 200 must never read as an empty listing: the sweep would
    # forget everything it holds.
    raise BasecampError(
        f"Basecamp: unexpected body for {_redact(str(url))}; nothing was synced or forgotten."
    )

The same review also changed how I handle Retry-After. My client used to sleep for whatever Basecamp asked, so Retry-After: 3600 meant a sync sleeping for an hour while cognee held its staging lock, and nan crashed time.sleep. Now any wait over 60 seconds stops the run as a rate limit so the next sync can retry, and a zero, negative or unreadable value uses exponential backoff. Every one of these fixes has a test that fails when I revert the fix.

Auth, and some small things the API taught me

Basecamp uses OAuth through 37signals Launchpad. examples/authorize.py does the one-time browser step and saves the tokens. Access tokens expire after two weeks, so the client can take a refresh token with the client id and secret and refreshes once on a 401. (I found that out the practical way: the token I tested with expired while I was writing this post.)

Other things I learned from the live API:

Basecamp's docs ask for a User-Agent on every request that names your app and a way to contact you, so the connector makes you pass one.
An expired trial or suspended account answers 404 with a Reason: Account Inactive header. I turned that into its own error, because "not found" is a confusing message for "your trial ended".
Completed to-dos are already in the default listing with completed: true, so no extra request is needed.
Message titles arrive with a trailing newline.
The token is never put in an error message. URLs in errors are redacted.

Tests

The tests run against an in-memory fake of the Basecamp API that copies what the live account did: ETags and 304s, trash, purge, archive, Link paging. One test runs through cognee itself (with the LLM mocked) and checks that both a trashed item and a purged item actually leave the knowledge graph.

Limits

Only active projects are read (the API default). Archiving a whole project removes its items on the next sweep.
Card tables, schedules, chat, uploads and check-in answers are not synced yet.
A purged item is only noticed on the next sweep, every 10th run by default.

Try it

The code is in packages/connector/basecamp/ in cognee-community. Register an app at launchpad.37signals.com, run examples/authorize.py, then examples/example.py. If your team lives in Basecamp, I would love to hear what you ask it first.

Teaching an AI agent what our newsletters said: a Mailchimp connector for cognee

Anand Prakash Srivastava — Sat, 31 Oct 2026 12:12:55 +0000

Every company that sends newsletters has the same small problem. Someone asks "when did we tell customers the new pricing starts?" and the answer is sitting in a campaign from two months ago. Nobody remembers which one. You end up scrolling through Mailchimp's campaign list and opening emails one by one.

For Mergetober I wrote a Mailchimp connector for cognee, an open source memory layer for AI agents. It pulls your campaigns (and, if you want, the notes you keep on contacts) into cognee, so an agent can answer questions about what you actually sent. It is PR #428 in cognee-community, for issue #4784.

Most of the work turned out not to be "call the API". It was getting clean text out of an email, and working out when a campaign has changed when Mailchimp does not tell you.

How I use it

I set up a small product launch across three tools to try this properly: the discussion in Twist, the tasks in Basecamp, and the customer announcement in Mailchimp. I wrote connectors for all three (the Twist and Basecamp posts are separate). The Mailchimp part is the customer facing side: what did we actually tell people, and when.

My account has a campaign called "Checkout launch(march)" whose email says the new checkout ships on 15 March and that the payments team owns it. After a sync this is the document cognee gets. Real output from my account:

Mailchimp campaign: Checkout launch(march)
Subject: New checkout is coming
Audience: Anand Test Workspace
Status: draft; a send started on 2026-10-16 was stopped

Checkout launch

The new checkout flow ships on 15 March. The payments team owns it.

That status line is real too, and there is a story behind it further down.

Using it looks like this:

import os
import cognee
from cognee_community_connector_mailchimp import mailchimp_source

api_key = open(os.path.expanduser("~/.mailchimp_key")).read().strip()

await cognee.remember(
    mailchimp_source(api_key, include_unsent=True, include_notes=True),
    dataset_name="mailchimp",
    write_disposition="merge",
)
print(await cognee.recall("When does the new checkout ship, and who owns it?", datasets=["mailchimp"]))

For this test I used Gemini for extraction and answers, with local embeddings. I added a second draft, "Pricing update", through the API so I could test a hand-coded HTML campaign too. Then I asked questions, deleted that draft, synced again and asked the same question:

Step	Question	Answer from cognee
Sync (2 campaigns + 1 note)	When does the new checkout flow ship, and who owns it?	"The new checkout flow ships on 15 March (2026) and is owned by the payments team."
	When does the new pricing start and what will the Starter plan cost?	"The new pricing starts on 1 April, and the Starter plan will cost 9 EUR a month."
	What does the contact prefer to hear about?	"Updates about the checkout redesign."
Delete "Pricing update", sync again	When does the new pricing start and what will the Starter plan cost?	"...there is no information about when the new pricing starts or what the Starter plan will cost."

After the delete I also checked the graph directly. There was no node left for Starter, pricing, 9 EUR or April, while "new checkout flow" and "payments team" were still there. That is the behaviour I wanted: deleting a campaign in Mailchimp should make the agent forget it, not just hide it.

How it is put together

One document per campaign, keyed campaign:<id>: title, subject, preview text, audience, sent date or status, then the email text, plus the archive URL.
With include_notes=True, one document per contact note. The note is tied to the contact's name. The email address is only included if you also pass include_contact_email=True, and address, phone and birthday fields are never requested at all.
Every row carries a node set mailchimp:<audience_id>, so you can scope recall to one audience. I used the audience id, not the name, so renaming an audience does not split its documents in two.
It is a dlt source, loaded with write_disposition="merge". Deletes are rows with _deleted: True, which dlt removes and cognee then forgets.

The API key decides the host

Mailchimp keys look like <32 hex characters>-us22. The part after the dash is the data centre, and the API host is https://us22.api.mailchimp.com/3.0. I build the host only from that suffix, after checking the key's shape, so user input never ends up in a URL:

_API_KEY = re.compile(r"^[0-9a-f]{32}-([a-z]{2,}[0-9]+)$")

def data_centre(api_key: str) -> str:
    match = _API_KEY.match(api_key.strip())
    if not match:
        raise ValueError(
            "That does not look like a Mailchimp API key "
            "(32 hex characters, a dash and the data centre, e.g. ...-us22)."
        )
    return match.group(1)

The key never goes into a log line or an error message. Error messages name the endpoint with ids replaced (campaigns/{id}/content), so a stack trace does not leak which campaign or contact it was.

Getting the text the author wrote

I assumed plain_text would be the easy answer. It is not. Campaigns made in Mailchimp's current builder have no plain_text at all until they are sent. And after sending, this is what you get:

One sentence of content, surrounded by "View this email in your browser", two "Logo" lines, a footer, and unresolved merge tags like *|UNSUB|* and *|LIST:COMPANY|*. Send that to an LLM for graph extraction and you are asking for entities like "Logo" and "mailing address" next to your real content.

archive_html turned out to be better. It exists before sending, and its merge tags are already resolved. So the connector parses archive_html with Python's HTMLParser and skips three things:

the hidden preheader (display:none),
the footer block (Mailchimp marks it with classes like mceFooterSection),
the "View this email in your browser" link, which points to campaign-archive.com before sending and mailchi.mp after.

The tests use two real archive_html captures from my account (ids replaced), so if Mailchimp changes its template markup, a test should notice.

Knowing when a campaign changed

This was the real design problem. Mailchimp campaigns have no "updated at" field. The listing can filter by send time or create time, and the issue suggested since_send_time as a cursor. I tried it on the live account:

It returned 0 campaigns while two drafts existed.
It missed a rename of a sent campaign.
It can never show you a delete.

So I dropped it. Every run lists every campaign (1000 per request, asking only for the fields I need), and for each one compares a small set of fields with the previous run:

def _signal(campaign: dict) -> list:
    settings = campaign.get("settings") or {}
    recipients = campaign.get("recipients") or {}
    status = "sent" if campaign.get("status") in SENT_STATUSES else campaign.get("status")
    return [
        status,
        campaign.get("send_time") or "",
        settings.get("title") or "",
        settings.get("subject_line") or "",
        settings.get("preview_text") or "",
        recipients.get("list_id") or "",
        recipients.get("list_name") or "",
    ]

A sent campaign cannot be edited, so its text is fetched once and again only if one of these fields moves. Drafts are trickier: I edited a draft's body and no field changed at all. So drafts (opt-in with include_unsent=True, because unfinished drafts are often full of template placeholder text) have their content read every run and compared by a content hash. Notes are similar: adding or deleting a note never moves the contact's last_changed, so notes are read every run, but only for contacts that have a last_note.

Two live runs back to back, today:

The send that got halted

Here is the story behind that status line. While I was testing, I sent the checkout campaign to my own test audience. Mailchimp put the new account under review and halted the send. On the API side:

the status went from sending back to save, but send_time was kept,
and archive_html stopped being HTML. It became plain text with one <br /> per line.

My HTML parser let the whole footer through on that run, because there were no footer classes left to match. I would never have thought to test for this. Now the connector detects an archive_html with no tags other than <br>, treats it as plain text and trims it like plain_text, and the status line says "draft; a send started on 2026-10-16 was stopped" so the agent does not claim it was sent. There is a test built from that exact capture.

These were my live runs on the account:

Run	Change in Mailchimp	Result
1	First sync (campaign in `sending`, one contact note)	1 campaign + 1 note, without the email address
2	Nothing	0 changed
3	Send halted by Mailchimp; a new empty draft created	both re-read (this is where the footer leaked; fixed and rerun)
4	Template applied to the new draft	1 changed (content hash)
5	Draft text edited	1 changed, next run 0
6	Halted campaign renamed	1 changed, next run 0
7	Draft deleted	1 deleted, row gone; next run 0 deleted

Forgetting, carefully

A campaign or note missing from a complete listing becomes a _deleted row. Three things stop that from going wrong:

A 404 is never a delete. /reports/{id} keeps answering for a deleted campaign, so it is never used to check.
Offset paging can skip an item. If a campaign is deleted between page 1 and page 2, everything shifts and one item can be missed for that run. So if a listing's total changed while it was being read, the run forgets nothing and the next run decides.
Mass deletes wait one run. If more than half of what was synced is suddenly gone (and at least 10 items), which is what a wrong audience filter looks like, the deletes are held and reported as held_back. The next run forgets the ones still gone and keeps the ones that came back.

I did not get that last one right the first time. My Twist connector had the same logic, and the reviewer there found that a batch was only confirmed if the next run saw exactly the same items gone. Delete a couple more campaigns in between and the batch was held again, forever. I fixed it in Twist and then applied the same fix here, along with the Retry-After edge cases from the same review (0, negative and nan now use backoff, and any wait over 60 seconds stops the run as a rate limit, since cognee holds its staging lock while a source runs). Each fix has a test that fails when the fix is reverted.

Tests

The tests run against an in-memory fake of the Mailchimp API built from what the live account returned. No key needed. One test goes through cognee itself, with the LLM mocked, and checks that a deleted campaign and a deleted note leave both the Data records and the graph.

Limits

Every run lists every campaign. With drafts on, each draft's content is fetched every run; with notes on, one request per contact that has notes.
Images are dropped. Automations, landing pages, templates and reports are not synced.
Archived campaigns follow Mailchimp's documented archived status and are covered by tests, but I could not check them live. Mailchimp only lets you archive sent campaigns, and sending was disabled on my account while it was under review.
Anyone who can read the cognee dataset can read the synced text and notes, so keep it in its own dataset.

Try it

The code is in packages/connector/mailchimp/ in cognee-community. Create a key under Account & billing, Extras, API keys, then run examples/example.py. If you have years of newsletters, I am curious what you end up asking it.

Giving an AI agent memory of our Twist threads: building a Twist connector for cognee

Anand Prakash Srivastava — Sat, 31 Oct 2026 12:02:20 +0000

Twist is built for long, slow conversations. Someone opens a thread with a proposal, people reply over two or three days, and somewhere around the fifth comment the actual decision gets made. That is great for a team, but it is terrible if you want to ask "what did we decide about X?" later. Search finds the thread. It does not find the answer.

So for Mergetober I built a Twist connector for cognee, an open source memory layer for AI agents. You point it at a Twist workspace, it pulls threads and channels into cognee, and then you can ask questions in plain language. It is PR #364 in cognee-community, for issue #4736.

This post is how I use it, how it works inside, and the bugs a reviewer found that I would never have found on my own.

How I actually use it

To try this properly I set up a small product launch the way a lot of small teams actually run one: the discussion in Twist, the tasks in Basecamp, and the announcement email in Mailchimp. I wrote connectors for all three during Mergetober (the Basecamp and Mailchimp posts are separate), and the point is to sync them into one cognee setup and ask about the launch without opening three apps.

In Twist I have a #launch channel with a thread called "Checkout redesign". The opening post says "Final call: option B ships first, on 15 March." and the comments confirm it. After a sync, this is the document cognee receives for that thread. This is real output from my workspace:

Twist thread: Checkout redesign
Channel: #launch in Anand Test
Started by Anand Prakash Srivastava on 2026-10-10

Final call: option B ships first, on 15 March.

Anand Prakash Srivastava on 2026-10-10:
_Final call: option B ships first. Confirmed by QA and design._

Anand Prakash Srivastava on 2026-10-11:
_Ship date confirmed._

Then I ask:

import json, os
import cognee
from cognee_community_connector_twist import twist_source

token = json.load(open(os.path.expanduser("~/.twist_tokens.json")))["access_token"]

await cognee.remember(
    twist_source("254427", access_token=token, channel_ids=[852087]),
    dataset_name="twist",
    write_disposition="merge",
)
print(await cognee.recall("What did the team decide about the checkout redesign?", datasets=["twist"]))

These are the results I got on my workspace. I ran this one without an LLM key, in cognee's keyless mode, so recall returns the best matching passage instead of a written answer:

Step	Question	Top result
Sync #launch and #Twist	What did the team decide about the checkout redesign?	"Checkout redesign": "Final call: option B ships first, on 15 March."
	What to do next in Twist?	the "What to do next" thread
Delete "What to do next" in Twist, sync again	What to do next in Twist?	"Get started in 4 steps". The deleted thread is not returned any more

That last row matters to me more than the first two. If memory keeps things you deleted, you stop trusting it.

The design in one picture

A few decisions shaped everything else.

One document per thread, not per comment. My first idea was to send each comment as its own document. But the decision is usually in comment five, and comment five only makes sense next to the opening post. So a thread becomes one document: title, channel, opening post, then every comment in order with author and date. Each channel also gets a small document of its own. Every row is tagged with a node set like twist:<workspace_id>:<channel_id>, so you can scope recall to one channel later.

It goes through dlt, with merge. cognee accepts dlt sources directly. The connector is a dlt source that yields rows keyed by thread:<id>. When a thread disappears, it yields {"id": "thread:123", "_deleted": True} and dlt removes the row. cognee's orphan cleanup then removes the document and its part of the graph. One thing caught me early: remember() defaults to write_disposition="replace", which quietly breaks both incremental sync and deletes. You have to pass "merge".

Figuring out what "changed" means in Twist

This took longer than writing the code. Twist's docs give you last_updated_ts and comment_count on a thread, and my plan on the issue used those two. Then I tested it against a real workspace, one change at a time, and wrote down what moved:

What I did in Twist	`version`	`last_updated_ts`	Anything on the thread?
New comment	moves	moves	yes
Edit the opening post	moves	no	yes
Delete a comment	moves	no	yes
Edit the latest comment	moves	no	yes
Edit an earlier comment	no	no	nothing at all
Bookmark the thread	moves	no	yes, but the text did not change

So last_updated_ts misses most edits. There is a version field that catches nearly everything, but it is not in the documented thread object. It is in the API response though, so the connector compares four values per thread:

signal = [
    thread.get("version"),
    thread.get("last_updated_ts"),
    thread.get("comment_count"),
    thread.get("channel_id"),
]
if not sweep and old and old[:4] == signal:
    stats["unchanged"] += 1
    continue

Bookmarking moves version too, even though nothing in the text changed. To avoid sending that to cognee, each rendered row gets a SHA-256 hash, and if the hash matches last run, the row is skipped.

The earlier comment edit is the annoying one. Nothing on the thread moves, so no cheap check can see it. The connector re-reads every thread's comments on the first run and every 10th run after that (full_sync_every), or when you pass full_sync=True. It is not instant, and the README says so.

Here is what two runs back to back look like on my workspace today. First run sends everything, second run sends nothing:

When I was testing, I went through the cases one by one on the live workspace:

Run	Change in Twist	Result
1	First sync	15 threads + 4 channels, the archived channel skipped
2	Nothing	0 changed, 15 unchanged
3	New comment on one thread, another thread deleted	1 changed, 1 deleted, 13 unchanged
4	Opening post edited	1 changed (caught by `version`)
5	Thread bookmarked	0 changed (content hash)
6	Latest comment edited	1 changed
7	Earlier comment edited	normal run: 0 changed. `full_sync=True`: 1 changed

Some other things the live API showed me that are not obvious from the docs:

A deleted comment does not disappear. It stays in comments/get with deleted: true and the content "-". If you do not filter it, your memory gets a line that says "-".
Renaming, moving or closing a thread adds a system message as a comment. Those are skipped too.
A thread's is_archived is not an archive. It is your own Inbox "done" state. I almost used it to drop threads.
comments/get without a range returns the last N comments, not the first. So comments are read in explicit from_obj_index / to_obj_index windows of 500.
A rejected token comes back as HTTP 403 with error code 200, not 401.

The part I underestimated: not deleting things by mistake

Forget-on-delete sounds simple. A thread missing from the listing gets a _deleted row. But "missing from the listing" is also exactly what a wrong channel id, a token that lost access, or a half-broken API response looks like. One bad run and the whole dataset is gone.

So there are a few rules:

A 404 is never a delete on its own. A deleted thread answers 404, but Twist uses the same error for something the token can no longer see.
Any API error stops the run before a single tombstone is written. dlt only saves state when the load succeeds, so the next run just retries.
If a run finds more than half of what it synced newly gone, and at least 10 items, it holds those back and reports them as held_back. The next run forgets the ones that are still gone and keeps the ones that came back.

The core of it is short:

gone = sorted(set(previous) - set(present))
pending = set(state.get("pending_delete") or [])
confirmed = [key for key in gone if key in pending]
fresh = [key for key in gone if key not in pending]
large = len(fresh) >= MASS_DELETE_MIN_ITEMS and len(fresh) > max_delete_ratio * len(previous)
if large and not allow_mass_delete:
    present.update({key: previous[key] for key in fresh})
    state["pending_delete"] = fresh
    stats["held_back"] = len(fresh)
    gone = confirmed

My first version raised an error instead of holding. The reviewer pointed out that a scheduled sync would then stop forever until someone noticed. Holding for one run fixes that without a manual step.

What code review taught me

goran-radonic reviewed this PR in three rounds. Every round found something real, and most of it was stuff my tests could not have caught because I did not think of the case. A few I remember:

Rolling deletes were held forever. My hold-back only confirmed a batch if the next run found exactly the same items gone. If you deleted a few more threads before the next run, the set changed and the whole batch was held again. Forever. The fix is the confirmed / fresh split above.
An archived channel could be lost. If you ran once with a wrong channel list, the mark that said "this archived channel was synced while active" got dropped, and the next normal run forgot all its threads. He wrote out the scenario run by run, and I turned it into a test that went through real dlt and SQLite. Before the fix it deleted 13 rows. After, 0.
Retry-After edge cases. I already stopped the run on any wait over 60 seconds, because cognee holds its staging lock while a source runs. But Retry-After: 0 made the client retry back to back with no wait, nan slipped through, and inf was not treated like a long wait. Now 0, negative and nan fall back to exponential backoff, and inf stops the run with TwistRateLimitError like any other long wait.
Stats from the previous run leaked. The counters reset in the wrong place, so a run that failed early reported the last run's numbers.

For the last round I did something I will keep doing: I reverted each of the 9 changes on its own and checked that at least one test went red. If a test still passes with the fix removed, it is not testing the fix.

Testing

The tests run against an in-memory fake of the Twist API that copies the behaviour I saw live: version bumps, deleted comments with "-", system messages, archived channels, 404s, comment windows. No token needed.

There is also one test that goes through cognee itself (add + cognify with the LLM mocked) and checks that a deleted thread actually leaves the knowledge graph while the others keep their ids. It goes red if you turn off either the tombstone or dlt's hard_delete hint.

Limits I am honest about

Every run lists all threads of the selected channels. That is one request per 500 threads, plus one per changed thread.
An edit to an earlier comment shows up only on the next sweep.
On Twist's free plan, the API hides comments older than one month. When an old thread is re-rendered, those comments drop out of memory too.
Images are dropped. Attachments are listed by name and link but not downloaded.
Direct messages are never read. That one is on purpose.

Try it

The connector lives in packages/connector/twist/ in cognee-community. The README walks through creating a Twist integration and getting a token with read-only scopes (workspaces:read,channels:read,threads:read,comments:read), and examples/example.py runs the whole thing.

If you use Twist and try it, I would like to know which questions you end up asking it. That tells me more than any test.

SniffDog: I built my job-hunting friend a sniffer dog that sniffs out malware in fake recruiter repos

Anand Prakash Srivastava — Sun, 04 Oct 2026 22:25:22 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

SniffDog checks a take-home coding assignment before you run it. It reads the repo, never executes it, and tells you in plain English whether it's safe to open.

I built it for my friend Mayank Raj. Earlier this year, Mayank, a final-year student hunting for his first developer job, got a LinkedIn message from a "recruiter" offering a remote junior developer role. The recruiter sent a GitHub repo and asked him to open it in VS Code and review the code. On the next call, he was asked to run the project live, so he ran npm install and npm run dev without reading it. Everything worked, and the call went well.

A few days later, he got a "new login" alert on his email and found an unknown session on his GitHub account. Malware had copied his saved browser passwords. He spent the weekend changing passwords, revoking tokens and wiping his laptop. The recruiter's profile was gone.

SniffDog is what I wish he'd had before he opened that folder.

What happened to Mayank wasn't bad luck. Microsoft has tracked the Contagious Interview campaign since at least December 2022: fake recruiters send coding exercises that run malware through dependency installs and repository tasks. In 2026, Elastic Security Labs found the same trick aimed at their own community Slack, with the payload hidden inside SVG images and obfuscated JavaScript. One developer told The Register he was "30 seconds away" from running one.

The trap fires the moment you run npm install, open the folder in VS Code, or start the dev server. A normal AI coding agent asked to "get this running" would do exactly that. SniffDog does the opposite: it looks first.

sniffdog https://github.com/recruiter/assignment \
  --company "Acme Labs" --recruiter "Jane Doe"

You get a verdict (🟢 SAFE, 🟡 CAUTION or 🔴 DANGER) with every red flag tied to a file:line, what it would do if you ran it, and what to do next.

Demo

Narration generated with ElevenLabs. The terminal output in the video is real SniffDog output on the repo's harmless demo assignment.

The repo ships a harmless demo assignment that copies the shape of real attacks: an install script that reaches the internet, a VS Code task that runs on folder open, JavaScript hidden inside a font file, and an obfuscated base64 payload. Every payload only prints "hello". Here is SniffDog reading it (trimmed):

🔴 DANGER
Static checks found 13 suspicious signal(s) in this repository.

Code snippets:
  - lib/config.js:7 (encoded-code) — unwrapped from base64:
    console.log('hello'); /* … */
    Gemma: The code prints 'hello' to the console.
  - package.json:6 (package-script):
    node scripts/setup.js && curl -s https://example.com > /dev/null
    Gemma: The code first executes the `setup.js` script
           using `node`, then fetches data from a URL
           and discards it.
  - public/fonts/inter.woff:1 (disguised-asset):
    console.log('hello from a harmless imitation font');
    Gemma: The code prints the text 'hello from a
           harmless imitation font' to the console.

memory: on
  - resembles known technique: alternate npm registry
  - resembles known technique: disguised font
  - …
tracing: on
Explainer: Gemma (local) read 3 snippets
Static checks only — nothing from the repo was executed.

A clean assignment comes back safe, and the recruiter web check adds context without changing the verdict:

Code

Anand-240 / sniffdog

SniffDog

Review coding assignment repositories before you run them.

Demo video: Watch SniffDog | DEV post: [DEV_POST_URL]

Why this exists

Fake recruiters send take-home repositories that hide malware. Microsoft and Elastic Security Labs have documented this Contagious Interview tactic. A trap may start during npm install, when a folder opens in VS Code, or when the developer starts the app. SniffDog reads the repository before those steps and does not run its code. It was built for a friend who got hit by one of these fake assignments.

What it looks like

The harmless suspicious demo triggers 13 findings, with file locations, rule explanations, and selected code snippets.

The safe demo has zero findings; public recruiter search results appear separately from its verdict.

Quick start

Install Python 3.12 or newer and Ollama on macOS or Linux. Start Ollama, then run:

ollama pull gemma3:1b
ollama pull nomic-embed-text
git clone https://github.com/Anand-240/sniffdog.git

…

View on GitHub

Python 3.12+, standard library only for the core. MongoDB and Sentry are optional extras that switch off cleanly when not configured.

How I Built It

SniffDog is a Python CLI built around one rule: deterministic checks decide how dangerous a repo is; Gemma only reads the code and explains it. The model can never lower the verdict.

repo URL or folder
  → safe clone (no hooks, no symlinks, https only, depth 1)
  → 5 static scanners: scripts · VS Code · obfuscation · assets · deps
  → base64 payloads decoded as data (never run), max 4 KB
  → Gemma 3 (1B, local via Ollama) reads up to 5 snippets
  → MongoDB Atlas: known-technique vector search + history
  → GitHub API + SerpApi: repo age and recruiter context
  → verdict 🟢/🟡/🔴 + next steps
  (every step traced in Sentry, metadata only)

What it catches

The scanners look for the tricks used in real assignment attacks: postinstall scripts that call curl, .vscode/tasks.json with runOn: folderOpen, .woff and .png files that are really JavaScript, code pushed 200 spaces off-screen, _0x obfuscator names, raw-IP URLs, a custom .npmrc registry, and typosquats like expres. Each rule has a hand-written, plain-English consequence ("When you run npm install, packages come from an unknown server…").

Debugging Gemma: from "summarize everything" to "read this code"

My first design asked Gemma to write the whole explanation. It went badly in three useful ways:

It claimed the user's system was "likely compromised", which a static scan can't know. I added a validator that rejects claims of completed harm.
Next it just copied the rule messages back, so it added nothing.
When I gave it only rule names, even gemma3:4b explained hidden code as "may cause rendering issues with extra whitespace". The model wasn't the problem. It had no code to read.

So I changed its job. SniffDog now unwraps the hidden payload itself, statically, and hands Gemma the real snippet. Asked "what would this code do if it ran?", the 1B model is accurate. Every URL it mentions must appear in the snippet, or the sentence is dropped.

Debugging with Sentry

Sentry tracing showed a full scan takes 5.16 s, and the local Gemma call is 3.59 s of it (~70%). That's why Gemma reads at most 5 snippets with a 30 s timeout. The trace also showed the Atlas memory lookup taking 1.52 s, mostly the network round trip, while every local scanner finished in about 1 ms.

Two bugs surfaced along the way:

No traces arrived. The CLI exited before the SDK sent anything. Fix: flush before exit, including on errors.
Too much data. Sentry's debug log showed it auto-enabling its PyMongo and logging integrations, which can record query contents. I turned default integrations off. Traces now carry span names, timings and counts only, and a test proves no code, prompts or finding text leave the machine.

Other lessons

A real company isn't a scam. My first recruiter check flagged "Microsoft" as CAUTION, because the web is full of "Microsoft scam" warnings about impersonators. Now web results only add context ("Scammers have impersonated Microsoft before; verify on the official careers site") and can never change the verdict.
No hiding spots. My coding agent once made the scanner skip a .kilo folder because its own worktree lived there. That's a hole: an attacker could hide a payload in any folder SniffDog ignores. I reverted it. Skipping now needs an explicit --exclude.

Results

Repo	Verdict	Findings
Harmless demo assignment	🔴 DANGER	13 of 13 planted tricks
Safe demo assignment	🟢 SAFE	0
MDN todo-react	🟢 SAFE	0
MDN Express Local Library	🟢 SAFE	0
expressjs/generator	🟡 CAUTION	2 (`child_process` in test files)

I kept the Express Generator result on purpose. Many assignments say "run npm test", so code in test files that starts processes deserves a look. SniffDog has 17 unit tests, and a GitHub Actions workflow runs them plus a SniffDog scan on every PR that touches package files:

Limitations

SniffDog is a first look, not an antivirus. It reads files and matches known patterns, so a new trick can slip past it, and a SAFE verdict is never a guarantee. Package scanners like Socket and Datadog's GuardDog go deeper on npm packages; SniffDog focuses on the whole assignment repo (VS Code tasks, disguised assets, recruiter context) and explains it for someone who has never heard of a postinstall script.

Why Does Open Innovation Matter?

For this tool, a closed cloud model isn't just worse. In the safest setup it can't run at all.

It works where you should test untrusted code. Microsoft's own advice is to do take-home assignments in an isolated, non-persistent VM. The safest version of that VM has no network. A cloud API can't answer there; Gemma on Ollama can. I tested it with Wi-Fi off: same scan, same verdict.
It's free for the people who need it. Mayank is still job hunting. He shouldn't need a paid AI subscription to check whether a recruiter is trying to rob him again. SniffDog runs on my 8 GB MacBook Air with gemma3:1b.
A security tool should be inspectable. Open model, open code, deterministic rules: anyone can read exactly why SniffDog called something dangerous, and change it.
I could change the model's job, not just its prompt. When Gemma struggled, I could swap sizes in seconds (gemma3:4b ran, but froze my laptop and took two minutes), read its raw output, and redesign its role around what a small model does well.

One honest trade-off: the optional GitHub, SerpApi, Atlas and Sentry checks need the network. Everything that touches the code itself works offline.

My Agent Session

I built SniffDog with a coding agent, phase by phase, reviewing every commit and pushing back when it took shortcuts (like the .kilo skip above).

Prize Categories

Best Use of Gemma: gemma3:1b runs locally via Ollama and reads the hidden code SniffDog unwraps, so the explanation works on an offline, isolated machine.
Best Use of MongoDB Atlas: Atlas Vector Search matches suspicious snippets against known attack techniques (local nomic-embed-text embeddings), and Atlas stores scan history so a repeat scan shows "Scanned before on …". No source code is stored.
Best Use of Sentry Agent Tracing: every scan is a transaction with spans per scanner, memory and the Gemma call. Tracing found the CLI exit bug and showed ~70% of scan time is the local model. Metadata only, default integrations off.
Best Use of SerpApi: live web search checks the recruiter and company for impersonation reports, as context that never changes the code verdict.
Best Use of GitHub Copilot: a GitHub Actions workflow runs the tests and a SniffDog scan on every PR that touches package files, failing the check on DANGER.
Best Use of ElevenLabs: the demo video's narration was generated with ElevenLabs.