Prompt Adware: Audit AI Coding Tool Instructions and Cleanup

If an AI coding assistant starts inserting an unwanted service recommendation into unrelated conversations, check the persistent instructions it loads before blaming the current prompt. A reusable configuration change can influence more than one session, and deleting a chat does not establish that the instruction source has been removed.

Check Point Research’s November 3, 2026 report analyzes version 4.5.0 of the Haiou Codex bundle. Researchers describe persistent advertising added through agent instruction files and call this behavior “prompt adware.” They also observed the package in a threat actor’s toolkit, while explicitly saying that this does not establish that its author intended cybercrime. The report does not establish that the advertised gateway is malicious. The relevant defensive issue is an unapproved change to trusted agent instructions; an allegation of credential theft requires separate evidence.

The audit below is a proposed method for an administrator reviewing tools and configuration they own. It does not require downloading the bundle, reproducing its jailbreak, or executing its installer or uninstaller.

Identify what changed and what loads it

Start by writing down the observed symptom, the application version, the active profile, the working directory, and when the behavior first appeared. Preserve the response and relevant configuration references without including secrets or private project content in a broadly accessible ticket.

Then inspect the instruction sources used by that particular tool. Check global instructions, project instructions, enabled skills, extensions, and any configuration wrapper that was installed around the assistant. These are review categories, not an assertion that every tool loads every category. Record how each artifact enters the session rather than assuming that a familiar filename is always active.

For Codex, OpenAI documents a global and project instruction chain. In the Codex home directory, it uses the first nonempty global override or base instruction file. It then discovers project guidance from the project root toward the working directory, with at most one instruction file per directory and support for configured fallback names. A closer project instruction can therefore matter even when a global file looks normal.

A change in one row does not prove a change in another. A promotional instruction is evidence of output steering; it is not, by itself, evidence that requests were routed through the promoted service.

Preserve a narrow diff against a trusted baseline

Compare affected files with a known-good backup, approved repository revision, or configuration previously reviewed by the owner. Record the added instructions, removed safeguards, new include paths, and unrelated settings changes. If no baseline exists, mark that uncertainty and have the owner reconstruct the intended settings before cleanup.

Use file modification times as leads rather than a complete installation history. Build the change record from multiple references where available: the installation decision, package provenance, configuration diff, and the first observed unwanted behavior. Do not copy suspicious instructions into a fresh agent conversation as a way to explain the incident; describe their effect and preserve the original in restricted evidence.

Distinguish an intentionally approved style rule from an instruction that hides its commercial purpose or overrides the owner’s task. The review question is whether the instruction was authorized, where its authority came from, and which future sessions could load it. Promotional wording alone should not be used to label every third-party skill as malicious.

Restore approved instructions without destroying unrelated work

Stop starting new sessions with the affected profile while the owner prepares the change. Back up the identified configuration and record a reversible restoration plan. Restore only confirmed unauthorized edits from the trusted baseline, preserving legitimate project rules, user preferences, and unrelated local work.

If an added component is the loader, disable or remove it through the organization’s approved management process. Do not execute a suspect cleanup script simply because it is labeled an uninstaller. The purpose of a controlled cleanup is to account for the artifacts that changed and the paths that load them; an installer’s own success message does not supply that evidence.

When the effective provider destination changed, review the actual routing and access records with the responsible administrator. Decide whether credentials or sensitive content may have been exposed from those records and the configuration history. Rotate credentials when the incident evidence or response policy calls for it. Avoid claiming either “no data left the device” or “all keys were stolen” from an unwanted advertisement alone.

Retest the configuration and the behavior separately

Open a fresh session after restoring the approved files. OpenAI notes that Codex rebuilds its instruction chain at startup; restarting the relevant session matters when validating those changes. Confirm the active profile, working directory, and instruction sources before running a simple behavior check.

Use a small neutral task with no secrets, no network-dependent work, and no copied jailbreak text. For example, ask for an explanation of a harmless local sample file that the reviewer created. Run the same task from the formerly affected project and from an approved control directory. Keep the tool version and profile recorded so the comparison has a clear meaning.

If the symptom survives, return to the source map. Look for a different profile, ancestor instruction, enabled component, or wrapper restoring the previous configuration. Do not keep adding stronger counterinstructions until the advertisement disappears: that changes the visible response without establishing which persistent artifact remains.

Close with an inventory, not a single clean answer

A defensible cleanup record names the reviewed artifacts, their owners, the trusted baseline, the restoration diff, the fresh-session checks, and any remaining blind spots. Keep the artifact review separate from the behavioral result so a clean reply cannot accidentally stand in for a complete configuration audit.

For teams distributing coding-agent configurations, make approved instruction files and component origins reviewable, document the allowed provider destinations, and include instruction changes in normal change review. A package’s signature or checksum can establish that the downloaded bytes match its published artifact; the owner still needs to approve what those instructions ask the assistant to do.

Method: primary research and official configuration documentation reviewed November 6, 2026, with an original proposed audit worksheet. No jailbreak bundle was downloaded or executed, no persistent files were changed, and no cleanup outcome was tested for this article.

General product workflow

The following Penligent demonstration is general product context. It does not reproduce this research or validate the proposed checks above.