Adding stories during the sprint without commitment to complete them

The Developers don't need to negotiate with the Product Owner whenever they want to change the Sprint Backlog. At the beginning of the Sprint, the commitment is made to the Sprint Goal. There should be a mutual understanding that as the team works toward the Sprint Goal, they learn more about the total work needed to achieve it. The Developers may find previously unknown work that needs to be done or may find that some work they thought was necessary is unnecessary.

If, during the Sprint, the Developers are concerned about their ability to meet the Sprint Goal, then collaboration with the Product Owner may be necessary to help plan the best course of action to maximize value. However, if the Sprint Goal is not in jeopardy, the Developers are free to add or remove work based on their capacity, including work that may not otherwise be related to the Sprint Goal.

Having a well-ordered, well-refined Product Backlog can help the Developers. The Product Owner is accountable for ordering the Product Backlog, so the Developers should be able to look at the ordering and make an informed decision based on the ordering and capacity to do work to pull in something appropriate.

...there's "a space" left in the Sprints for the unplanned bug fixing - so the team appears in the situation, when the committed work in Sprint is done, while developers still have capacity.

If the commitment to having Done work was actually being met, there'd be no bugs to fix. In Scrum, Developers commit to the quality of their work expressed in a Definition of Done, not to an amount of work.

My understanding is that following the Scrum guide the Team can negotiate with PO taking more stories into the Sprint, if they feel they can commit to finish them.

Scrum is about learning to build the right thing at the right time under complex conditions of high uncertainty. A Product Backlog isn't just some sort of woodpile that people saw away at.

Developers should be committing to the Sprint Goal which mitigates a significant risk, and to the quality of the work they forecast for meeting that Goal. Once their Sprint commitments have been met, they can do whatever they want. 
 

...when the committed work in Sprint is done,...

According to the Scrum Guide, there is not "committed work".  There is a commitment to satisfy the Sprint Goal.  It is up to the Developers to determine what work is needed to do so.  

Also, no where in the Scrum Guide does it state that all items that have been included in the Sprint Backlog must be completed during the Sprint. That is a big misconception based upon misplaced understanding of the Sprint commitment. 

The Scrum Guide is not voluminous.  It does not contain a lot of extraneous information or explanations. It is fairly simple to read. It is available in a wide variety of languages, in case English is not your native one.  I refer to it frequently when I have a question or concern.  It might help you to explain this to your organization by looking at the Guide.  It can be found free of charge at https://scrumguides.org/ where it is maintained by the original creators, Jeff Sutherland and Ken Schwaber. 

Thanks Thomas, Ian, Daniel.

if the Sprint Goal is not in jeopardy, the Developers are free to add or remove work based on their capacity, including work that may not otherwise be related to the Sprint Goal.

Once their Sprint commitments have been met, they can do whatever they want. 

I take it from your comments, that more work can be completed in the Sprint, if developers have capacity and the Sprint Goal is not put in danger. And as Scrum guide mentions nothing about adding/removing such not-related to the Goal items to the Sprint itself, I conclude, it's up to the team. You are very welcome to point me to my mistake, if I'm wrong.
 

If the commitment to having Done work was actually being met, there'd be no bugs to fix. In Scrum, Developers commit to the quality of their work expressed in a Definition of Done, not to an amount of work.

Probably I wasn't clear enough in my explanation. The team doesn't plan to neglect the DoD and develop a feature with bugs. I'm talking about issues or gaps, discovered by end-users, or problems they encountered, while working with the living project. Those are continuously created and pushed by stakeholders directly to the team Sprint backlog for the team to fix. By project regulation, the team leaves about 20% capacity "free" each Sprint for such activities, and if no bugs assigned - this create the exact "spare" capacity I mentioned.

Those are continuously created and pushed by stakeholders directly to the team Sprint backlog for the team to fix. 

The Sprint Backlog is created, maintained and owned by the Developers.  No one should be adding any items to that backlog except for the Developers.  The method that has worked best for the teams I have worked with are to notify the Product Owner of the issue and let them put an item into the Product Backlog.  Then the Scrum Team can address the issue in accordance with their team practices.  Sometimes they will pull the item into the current Sprint, sometimes it will be included in a future Sprint and in some cases, the issue is never resolved.