FIELD NOTE / 2026.09.224 MIN READ / 5 SOURCES

Cruise 2023: The Autonomous Vehicle That Dragged a Pedestrian After a Crash

The 2023 Cruise pedestrian incident showed how autonomous vehicles need explicit post-collision behavior, truthful incident reporting, and software states designed for rare but dangerous edge cases.

The Cruise incident began with one crash and became a software-governance crisis

On October 2, 2023, a human-driven vehicle struck a pedestrian in San Francisco and propelled the person into the path of a Cruise autonomous vehicle. The Cruise vehicle initially stopped, then attempted a post-collision pull-over maneuver and dragged the pedestrian roughly 20 feet before stopping again.[1] The unusual sequence matters because the robotaxi was not the first vehicle to hit the pedestrian. The software failure concerned what the autonomous system did after an unavoidable secondary collision, when the safest behavior was to remain stationary.

Rare states are still part of the product

Autonomous systems spend most of their time in ordinary driving states, but safety depends disproportionately on what happens during unusual combinations such as impacts, blocked sensors, prone pedestrians and emergency scenes.

The collision-detection subsystem selected a maneuver that was normally sensible

Cruise’s Part 573 recall report said the collision-detection subsystem could cause the automated vehicle to attempt to pull over after a crash rather than remain stationary when a pull-over was not the desired response.[2] Pulling out of traffic is generally a reasonable post-incident action. The problem was context: the pedestrian was beneath or adjacent to the vehicle, so additional movement could increase injury. This is a classic state-machine failure in which a normally safe recovery routine becomes unsafe because the system has not represented an exceptional condition precisely enough.

The software needed to reason about post-impact uncertainty, not only road clearance

After a collision, sensors may be occluded, damaged or unable to determine whether a person or object remains under the vehicle. A conservative safety design should therefore treat uncertainty itself as a hazard. Motion-planning logic optimized to clear traffic can be inappropriate if the system lacks confidence that movement is safe. Cruise later said the updated software would have kept the vehicle stationary in the October 2 event.[2]

Recovery logic needs a stronger safety bias than normal driving logic

Once a collision has occurred, minimizing secondary harm should take priority over traffic flow or reaching a tidy roadside position.

California suspended Cruise’s driverless permits after the incident

On October 24, 2023, the California DMV suspended Cruise’s deployment and driverless-testing permits, citing unreasonable risk to public safety and misrepresentation of safety-related information.[3] This made the event larger than a software recall. Autonomous operation depends on regulatory trust that companies will accurately disclose how systems behave during serious incidents. If the regulator believes key details were withheld or incompletely presented, software assurance becomes inseparable from organizational transparency.

NHTSA’s recall formalized the software defect across the fleet

Cruise filed recall 23E-086 for approximately 950 vehicles equipped with the affected driverless software.[2] Treating autonomous-driving software as recallable motor-vehicle equipment is historically important. The “part” being recalled was not a mechanical assembly but a software subsystem governing collision response. The remedy was a new release that changed post-collision behavior before driverless operation would resume.

Software versions become safety configurations

In a robotaxi fleet, knowing which software build is running can be as important as knowing which physical component is installed. Configuration management becomes part of recall traceability.

Crash reporting became a second failure channel

In 2024 NHTSA entered a consent order with Cruise after concluding that several required crash reports were incomplete, including reports that omitted the post-crash dragging details.[4] Accurate incident reporting is a safety mechanism because regulators and engineers depend on those records to identify patterns. A company can have sophisticated telemetry and still undermine safety if critical facts do not reach oversight systems promptly and completely.

The episode helped change the trajectory of Cruise’s commercial program

The company paused driverless operations, undertook leadership and safety changes, and never returned to the same large-scale passenger robotaxi model. A 2026 California legislative background report summarized the permit suspension, the disputed crash presentation, and Cruise’s later retreat from passenger robotaxi service.[5] The software defect was therefore not only a local bug; it became a catalyst for a broader loss of regulatory confidence and strategic reset.

Trust is a deployable asset

Autonomous fleets require permission to operate in public. Once regulators and communities lose confidence in the developer’s reporting and safety process, technical improvements alone may not restore deployment quickly.

Why the Cruise 2023 incident belongs in software-failure history

The Cruise incident belongs in software history because it exposes the importance of designing explicit behavior for what happens after the nominal driving problem has already failed. The vehicle’s collision-detection subsystem chose a pull-over behavior that was reasonable in ordinary post-crash logic but harmful in the actual configuration.[1][2]

The deeper lesson is that autonomous safety includes recovery, reporting and governance. Developers must model rare post-impact states conservatively, preserve complete event data and communicate incidents truthfully. A system that drives competently for millions of routine miles can still fail catastrophically if its edge-state behavior and institutional response are weak.

RESEARCH / PROVENANCE

Works Cited

5 SOURCES
  1. 01
  2. 02
  3. 03
  4. 04
  5. 05

CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.

Contribute / Corrections

Improve the record.

Use this moderated submission form to suggest a correction, provide a source, challenge a priority claim or identify a missing contributor. Submissions are treated as research leads, not automatically published comments.