It sounds like an issue with the jsessionid parameter that portal likes. I believe wps uses the jsessionis to track your portal side session, so if you try to access some super long portal uri without a session, it tells you to go to the portal home and start over
This tells booster that if there is no jsessionid cookie and this parameter is specified, then redirect the user to the home URI. The issue I can see is that if you have an old jsessionid cookie (that is expired) and you access the home uri something like what you describe may happen. Perhaps upon Booster ESSO login we should always remove the jsessionid cookie?