Can an OBD2 Scanner Read Cleared Codes? What Remains

An ordinary OBD2 scanner cannot reliably recover a trouble-code record that the vehicle has actually erased. It may still find a permanent code, a newly detected fault, manufacturer-specific history or a report saved outside the vehicle.

Those are different kinds of evidence, not a universal undelete function. If you are checking a recently repaired or used vehicle, preserve whatever the controller currently reports and distinguish that from what someone says existed before clearing.

An empty code screen cannot reconstruct the missing history or prove that the car never had a fault.

Where a scanner gets its code list

During a fresh scan, the tool requests information retained by the controller. It is not searching an ordinary computer recycle bin. If the relevant record was erased and no separate supported record remains, changing to a more expensive reader does not necessarily bring it back. The important question is which controller and record category the tool can access, not simply whether it advertises advanced diagnostics.

Current vehicle data versus saved tool reports

A report stored in a phone app, workshop system or scanner memory can survive vehicle code clearing because it is a separate file. Check its date, vehicle identity and status labels. A previously saved report is valuable historical evidence, but it should be described as a prior capture rather than a code that the vehicle still reports today.

Coverage affects what you can see

Some tools read only standard emissions categories while others access manufacturer modules and history. A basic reader's blank list does not establish that every controller is clear. However, enhanced coverage is not a promise that a deleted engine record exists elsewhere. Verify the exact supported function before paying for a tool on the assumption that it can recover all past faults.

Credit: www.foxwelldiag.com

What clearing actually changes

The effects depend on the controller and command, but ordinary emissions clearing can remove stored diagnostic information and reset monitor readiness. The ELM327 technical documentation treats clearing as a vehicle diagnostic request, separate from adapter setup. Restarting an app is therefore not equivalent to clearing the vehicle, and neither action should be inferred solely from a fresh-looking screen.

Keep code categories separate

A stored or confirmed code, a pending code and a permanent code have different retention and reporting rules. Manufacturer history labels can introduce another category. Read the exact status rather than calling every visible code active. Likewise, the word cleared in a workshop note may refer to one controller or category, not an assertion that every diagnostic record in the vehicle was deleted.

Why a record may have been cleared

Code clearing can occur as part of a legitimate repair process or troubleshooting, and some power-related events can affect retained information. It can also remove evidence that a later buyer would find useful. A scan alone generally cannot establish the person's reason. Record the observable state and request maintenance records instead of treating a reset clue as proof of deliberate concealment.

What a follow-up scan can legitimately find

A later scan can retrieve records currently available through supported functions. It may find a condition that persisted, a fault that occurred again or a retained permanent entry. Match the code, status and capture date before deciding which explanation fits. The same alphanumeric code appearing twice does not by itself tell you whether the original record survived or the system detected the problem again.

A new pending code is not recovered history

If a monitor detects a fault after clearing, it can create a new pending record under its operating rules. That is new evidence from the current monitoring period.

Save the conditions and investigate the fault. Do not describe the result as a scanner recovering erased data, because that confuses a fresh detection with a retained old record.

A visible stored code may have returned

Compare the current report with any earlier saved report and the repair timeline. A code that returns under the same conditions may point to an unresolved or recurring problem.

It does not establish whether the first clear command succeeded.

The useful diagnostic question is why the controller is reporting the condition now, not whether the scanner possesses a hidden memory-recovery feature.

Permanent codes are the important exception

California BAR’s OBD reference explains that permanent DTCs cannot be removed by a scan-tool clear command or battery disconnection; the vehicle's OBD system must verify that the relevant fault is resolved. This is retained diagnostic information, not an undeleted ordinary code. The presence of a permanent entry therefore needs to be interpreted with current faults, warning status and monitor progress.

Permanent does not mean the fault must still be present

A retained permanent code can outlast a repair while the vehicle has not yet satisfied the conditions needed to clear that record. Conversely, a repair claim does not prove the condition is fixed.

Look at the available current evidence and follow the vehicle diagnostic procedure. Do not demand that a technician erase a category that is deliberately outside ordinary erasure control.

Readiness shows test completion, not a complete past

Incomplete monitors can be consistent with a recent reset, but they do not identify every former code or the reason for clearing. Monitor completion also depends on operating conditions and vehicle strategy.

Avoid translating several incomplete entries into a confident claim that a particular fault was hidden.

They establish an inspection limitation that should be recorded and resolved appropriately.

Understand what cannot be reconstructed

If no prior report exists and the controller no longer retains a fault, its exact number, freeze frame and sequence may be unavailable. A repair invoice or technician record may supply part of that history, but an ordinary scanner cannot manufacture it. Be explicit about the missing evidence rather than substituting a likely code based on the vehicle's reputation or symptoms.

Reset-related counters have limited meaning

The OBD Auto Doctor parameter list includes supported fields such as distance and warm-ups since codes were cleared. Availability varies by vehicle and tool.

These fields can describe the reported monitoring interval, but they do not name deleted faults or prove why the interval restarted. Record the exact field and units instead of turning one counter into a certainty about the vehicle's past.

Several factors change what remains visible

Controller design, code category, tool coverage and elapsed operation all affect the available report. A workshop may also have stored a scan separately.

Ask which source supplied each piece of information.

Keep an app's cached result distinct from a fresh controller response.

If the tool cannot show when a saved report was captured, do not present it as current evidence.

Credit: www.amazon.com

For a used-car check, preserve uncertainty

Ask for repair records and permission for an independent inspection that includes a current diagnostic scan. Record readiness, code categories and warning behaviour.

If monitoring is incomplete, recognise that some assessments remain unfinished.

Do not assume that a short drive will complete every monitor or that a clean first scan guarantees the absence of intermittent problems.

For your own repair, save both sides of the job

Capture the initial report before any intended erasure and keep the post-repair report separately. Include the fault conditions and what repair was actually performed.

This allows a later recurrence to be compared with real evidence rather than memory. A file named before repair is useful only if its contents identify the vehicle and capture date clearly.

When a code returns, diagnose its present cause

Use the exact manufacturer procedure and current conditions to determine what failed. Repeated clearing can postpone diagnosis and remove helpful context.

A recurring code should lead to a test that distinguishes likely causes, not a cycle of clearing and waiting in the hope that the scanner eventually stops displaying it.

Do not buy recovery promises without a defined function

Ask a vendor what it means by history or cleared-code reading. Does the tool retrieve a documented manufacturer record, show permanent DTCs or merely save its own earlier reports? Those are useful but different capabilities. A vague promise to reveal every erased code should not be treated as a verified feature for your vehicle.

More software does not restore absent evidence

A new app may expose a supported category that the previous reader did not show. That improves access to retained information, but it is not the same as reconstructing erased data.

Confirm the record source and category after switching tools, especially if the displays use different labels for similar diagnostic states.

A useful report separates fact from inference

Write that the scanner found a specified permanent code, that certain monitors were incomplete or that a prior report listed a fault. Label any inference about timing as an inference.

Avoid writing that the car was definitely tampered with or definitely repaired unless separate evidence supports that conclusion. Clear language makes the findings usable without exaggerating the scanner's capabilities.

Credit: www.launchx431.fr

What to do when the old code is gone

Search your saved reports and repair records, then investigate any current symptom with fresh evidence. Use the scanner-report guide to keep status categories straight.

If nothing remains, acknowledge that limitation. The responsible answer is what can be verified now, not a promise to recover a code the vehicle no longer stores.