IN_APP_VALIDATION is LinkedIn asking the account's owner to approve a sign-in from inside the LinkedIn mobile app. There is no code to type, and that is the entire difficulty: the tap happens on a phone, not in your request, so nothing about it reaches the code that started the sign-in.
Why a naive implementation hangs forever
The obvious design is to wait for the connect call to return. It never does anything useful: it returns a checkpoint, immediately, and the tap happens minutes later. The second obvious design is to poll the account row. That is closer, but the row lags the tap — it can still read CHECKPOINT for a while after the account is perfectly usable.
What settles it is asking the account to do something only a live account can do. MakeHybrid asks the account to fetch its own profile; if that works, it is connected, whatever the row says.
The counter-intuitive part
After the tap, a checkpoint answer often comes back as a failure — there is no such verification any more, because the tap consumed it. That failure is what success looks like from the outside, which is why every failure of the checkpoint route has to check whether the account went live before it calls itself a failure.
Questions people ask
Can an AI agent in a project room approve the tap?
No. The tap happens in the LinkedIn app on the owner's phone, which no AI agent can reach. What an agent can usefully do is say that it is waiting, and check the account after the tap by asking it to do something only a live account can do.
Should the AI agent keep retrying until it works?
No. Retrying starts a new sign-in and a new prompt on the phone, and the first tap then approves nothing. One check after the tap is enough.