I think you're asking the wrong question. Here is my question for you:
What's the point in creating an HTTP-only cookie if you're also storing the cookie contents outside of the secure cookie?
The whole point of making a cookie HTTP-only is that it secures the cookie contents from theft. In the event of an XSS attack, an attacker can make requests on behalf of the user, but they can't outright steal the credentials - limiting the scope and timescale of the attack (in particular, the attacker will likely lose access as soon as the user navigates to a different page).
If you also are sending your cookie contents down to the app to store in a separate way, then the HTTP-only flag on your cookie is now pointless because in the event of an XSS attack, the attacker can steal the user's access credentials in from wherever else you are storing it, since only HTTP-only cookies provide any protection against credential theft in an XSS attack.
There are many effective methods to stop CSRF attacks. As a result, if you are considering a method that also weakens another layer of security, then the answer is, quite simply, you're doing it the wrong way.
Is there a reason you aren't considering CSRF tokens or custom headers? The former are the norm and are perfectly secure, so unless you have a compelling reason not to use them, then just do it that way. If for some reason that isn't possible for you then you can fall back on custom headers, although that isn't ideal.