I'm going to be really blunt...
- Are you in charge of the developers in this job?
- Are you the project leader?
- How much "stake" do the developers hold in the project?
- What is your business justification for a rewrite?
- What is it about the code base that makes it entirely useless and unrecoverable?
You've stated that you have just started a job, and yet you already appear to be a master of the situation there. Perhaps I have misunderstood the intent of your question, but I get the impression that you've entered a job where you see a number of problems, and you have jumped to the easiest conclusion in which the code is broken and the only way forward is a rewrite, but have you really considered the cost to your employer to do so?
With any existing code base - no matter how poor a state it is in - the owner will usually have a sizable investment in the product(s) the code represents. There are both direct and indirect costs associated with the code base, and a rewrite is often the very last thing you want to do as a software developer, as you risk devaluing your code assets, and thus getting a lower return on all of your prior efforts.
Take the Window's operating system as an example. With each new version created, there has been a big chunk of code carried forward from the previous version. Sometimes, entire libraries and APIs are dragged forward across several generations of OS. Why? Because the developers know that these elements work, have been tested, have been patched and fixed to prevent security and memory problems, and because they have cost a hell of a lot of money to get into that state. Nobody wants to throw away working code when it is making them money, even if the maintenance costs are relatively high, the cost to start from scratch will always be higher still, and in a company like Microsoft's case, they have billions in the bank which allow them to start from the beginning if they want to, but they don't because they want to maximize their return from their investment. Your employer is no different to Microsoft, except for the bit about having billions in cash to throw at a project.
So the code is a mess, and it sounds like there are communication and boundary issues between the various areas of the company. What can you or your colleagues do about this?
One option is to simply continue on as the team has been, and hope for a miracle in the future. Probably not a good idea, and likely to only increase your frustration and stress.
A better option is to simply knuckle down and do your jobs, but as a part of this look for opportunities to add tests to support those areas of code that appear to be the most fragile, then refactor them until they become more stable. You'll have an easier time making a compelling argument to improve the company's investment instead of arguing to simply throw it all away.
An even better option is to be organised as a team, and to ensure you get someone on side with enough seniority that they can make a good case to allow the team more flexibility to schedule time to improve the code base. I don't care how busy a company is, or how rigid the schedule appears to be, there are always the occasional "lulls" in activity that can be used to squeeze in an improvement or two. It's even better however if the improvements can be made while completing other tasks. If it were me, I'd be cozying up to a manager and introducing them to concepts in some of the canonical books that software developers read. Clean Code is probably the one your team needs the most. Plant a few seeds about how to improve the code, and provide a few examples of what you mean. A good manager will see the value of adding incremental improvements to code, especially if you are able to describe the concept of Technical Debt. Help your team leader or manager to make a good business case for improving code, and they'll have a better motivation to act on it.
It's also not enough to say "the code is untidy". You need to encourage your colleagues to practice coding clean all of the time, and to use clean coding technique to encourage a little tidying up as you go. I have a little poster that I print out and hang from my office wall every time I take on a new job. It says "Always strive to leave the code a little more beautiful than you found it". Right next to it I add another which says "Lilies don't need to be gilded". They both serve to remind me that I should always try to improve what I find, but avoid simply gold-plating one problem with another. Massive rewrites are often the worst sort of "gold-plating", because they are often done for the wrong reasons. Sure an entirely new product version might be justifiable at some point, but rarely simply because the code base is a mess.