TL;DR
You have a very new team, and everyone involved in the project is new to their Scrum roles. Furthermore, the Scrum implementation itself seems flawed, since the team is using Scrum labels without evidence of having truly adopted the roles, responsibilities, values, and events required of a successful Scrum implementation.
In short, you most likely have both a framework problem and a communications problem. The team as a whole needs to address both.
Unpacking the Anti-Patterns
Let's try and unpack the entire series of anti-patterns buried in your question. The top four seem to be:
You have a "project manager."
There is no project manager role in Scrum. The only three roles in Scrum are Product Owner, Scrum Master, and Developer. If you have additional roles formally attached to your team, you aren't actually doing formal Scrum because:
[A]lthough implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety[.]
You aren't minding your own business.
When you make comments like "[s]he seems to eating into PM role" you are worrying about the delineation of roles (and possibly political concerns) that don't have anything to do with you. Unless you're the project manager or the Scrum Master, you don't have any obvious skin in the game. Unless there's an impact on the team (we'll get to that in a moment), the best thing you can do is mind your own business and let the PM and SM work it out between themselves.
The term "bossy" is often sexist.
Micromanagement can be a legitimate problem, but in American English the term "bossy" is often used pejoratively to describe behavior by a woman that would be considered a perfectly legitimate management style when performed by a man. So, make sure you aren't coloring this with cultural or personal preconceptions about what female leadership or female management styles should look like.
If it turns out that your newly-minted Scrum Master is truly directing (rather than coaching or refereeing) the newly-minted Scrum Team, then you may have a legitimate concern that should be brought up respectfully and constructively in the next Sprint Retrospective. Learning the responsibilities of a new role is always challenging, and that goes for your entire "new to Scrum" team, not just the Scrum Master.
The entire Scrum Team needs to continuously refine its internal processes to fit the needs of the project, as well as the skills and abilities of the team members. This doesn't happen overnight, and is why teams generally go through the three of the four stages of group development (e.g. forming, storming, and norming) before they can successfully get to the "performing" stage.
Scrum is not based on "autonomy."
While self-organization and continuous process improvement are central to Scrum theory and values, the underlying principles are about collective ownership and collaboration, rather than "autonomy" in the sense of doing things your own way without regard to the impact on the team as a whole. There's no place for "cowboy agile" in Scrum.
As a member of the Scrum Team, you should certainly be addressing any process issues constructively with the rest of the team. At a minimum, your Sprint Retrospectives should be addressing issues with the team's process, with a focus on how to collectively iterate towards a more effective process for the project.
Whether or not you end up doing real Scrum or just a Scrum-like implementation, you need to improve the level of communication within the team and between team members. Without effective interpersonal communication, and without continuous conversations about how to improve the team's process, nothing will change for the better.
