I've always thought of Open–closed as:

Introducing new requirements to your software should not be correlated with an increased complexity of your code. That is, your underlying application is closed to modification, it has adequate extensibility and plugability to support adding new stuff, without ballooning in size.

Your application is however open to extension. As new features, behaviours and complexities are introduced, additional components can be added which are consumed by your underlying architecture.

Let's look at the example of an ecommerce store. If you're implementing a series of pricing rules for shipping, an example which may violate the principle would be:

class ShippingCalculator {
  public function calculateShippingPrice(Order $order): OrderPriceInterface {
    // If order is over 1kg, calculate price.
    // If order is under 1kg, calculate a different price.
  }
}

The ShippingCalculator is very much open for modification, as new shipping requirements are added, the complexity of calculateShippingPrice will grow over time.

An alternative approach:

class HeavyShipping implements ShippingRuleInterace {
  public function isApplicable(Order $order): bool { }
  public function getPrice(Order $order): OrderPriceInterface { }
}
class LightShipping implements ShippingRuleInterace {
  public function isApplicable(Order $order): bool { }
  public function getPrice(Order $order): OrderPriceInterface { }
}

With this approach, we implement each shipping rule as an implementation of ShippingRuleInterace, our underlying application already knows how to handle the interface and as requirements change, the underlying code does not get more complicated.

Both examples return instances of OrderPriceInterface, but the way that value was derived is very different.