Existence of a remember token in multi-guard system breaks CSRF matching

First of all, I will say I've worked around this problem entirely; I'm asking this question more out of curiosity and to better understand how this part of Laravel works.

I'm working on a web app that has two guards for logging in to different areas of the site, lets say 'web' and 'admin' for this example. Each guard uses a different Eloquent model.

I log in to the admin area, checking 'remember me'. I then log in to the web area, do some things, and log out again. In my logout() methods in my LoginControllers I invalidate the session, which obviously would normally log out the admin area too, if not for the remember cookie.

At this point, trying to log back in to the web area causes a TokenMismatchException and a fresh CSRF token to be generated on each request. Refreshing the admin area (which is still logged in via the remember cookie), or deleting the remember cookie, causes the CSRF to stop changing on every request and everything works as normal again.

I've avoided this issue by explicitly logging out all session-based guards when any individual one logs out, which clears any remember tokens that have been set. As the two parts of the site are disjoint in terms of who will be using them, this shouldn't cause anyone any inconvenience, so no worries going with this option.

But, looking through the appropriate middlewares, I can't see anything that would make the presence of a remember cookie cause issues.

I would expect the following to happen:

• Log out of web guard, invalidating session
• Redirected to login page, with newly generated session and CSRF token
• Log in, CSRF is compared with the value I was just redirected with, and correctly matches
• Upon next page load on the admin guard, the old session is no longer present and the new session has no login state for that guard. But there is a remember token set, so I am authenticated via that, and my login state for that guard is added to the session.

Instead, I get to step 3 and the token never matches. I can't for the life of me work out where the token it's trying to match against is coming from. Seems like something is causing an entirely new session to be generated before the token is checked, but there doesn't seem to be any reason. From what I can see, the token verification step happens long before any sort of user authentication, so I'm stumped.

Any thoughts?