When you do PI Planning, you aren't planning at the Story level. PI Planning looks at the Program Backlog, which holds Features and Enablers. The Team Backlog has Stories along with Enablers.
Going into PI Planning, the intention is that Product Management and System Engineering are refining the items in the Program Backlog. Through this refinement, the Product Managers and System Engineers clearly define the Features and Enablers and work with the teams who are likely to do the work to ensure technical feasibility and find ways to split the work into smaller chunks (Stories and smaller Enablers). The split work may not be exactly what ends up on the Team Backlogs, but it is close. This act of decomposition can help the teams develop better estimates and plans for the PI.
Prior to PI Planning, Product Managers and System Engineers work with Product Owners to get more insights and refinement prior to involving all the Agile Teams in PI Planning. This usually happens in the two or so weeks leading up to the PI Planning events. This often aligns with the Innovation and Planning Iteration.
It's expected that, throughout the Program Increment, more work will emerge. By doing the work, the teams will find more things that they need to do or that work is more complex than initially thought but may also find that some work that they expected is not necessary or less complex.
You'll mitigate some of the problems if you spend more time just before and during PI Planning to put the more detailed work into the Team Backlogs, instead of putting the items directly from the Program Backlog into the Team Backlogs. Establishing traceability between the ongoing refinement at the Team Backlog level and the work in the Program Backlog selected for the Program Increment would help to support visibility.
The biggest issue is welcoming late changes, which is a principle of Agile Software Development. Developing a plan for a Program Increment of 8 to 12 weeks (2 to 3 months) with reasonable confidence is difficult if your environment is changing at a faster rate. Stable long-term plans and welcoming late changes, either in the form of newly discovered bugs or in changes to stakeholder needs, are at odds with each other. It's compounded by the fact that these bugs or more urgent needs may not align with the Features or Enablers selected for the Program Increment and the organization is forced to make a choice to welcome these changes or hold to the plan.
The long-term planning aspects of SAFe are one of the reasons why people say that it isn't an agile methodology. The long-term planning at the portfolio, solution, and program levels can hamper a team's ability to respond to changing requirements and new information that is learned by demonstrating or delivering working software. The best option to better handle change is to shift away from some of the SAFe structures that push planning down from the organization onto the teams.