anything obviously wrong with my custom password hash scheme? i sha2-256 hash the password, then i base64 encode the hash (per RFC 2045) , resulting in a 44 bytes string looking like LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ= , then i bcrypt ...crypt() that (using a securely generated salt), and i get something like $2b$10$HyPnAMyB2l1onzLjxEeRHuSioZ/X31I/XP6oHa.SPHA7KxJbR9Jq.

anything obviously wrong/bad with that scheme?

and if you're wondering why i'm doing it like this: 
bcrypt crypt() (at least the implementation i'm using) has 2 annoyances, most importantly, it can't handle NULL bytes,
it thinks "\x00foo" is the same as "\x00bar". secondly, it only considers the first 72 bytes of the input password. sha2-256 don't have the NULL issue, nor the length issue, but the resulting hash can contain NULL bytes, and base64 encoded data never contains NULL bytes, and i thought the resulting 44 bytes string would be a great key for bcrypt...?
I am hesitant to say that this is "okay" because it probably is from a strictly cryptographic point of view, because if I do you will stop reading and go with your solution. Some thoughts:

In the word "password" there's the word "word". Passwords are meant to be typed in by humans, therefore they must at least be printable, therefore ASCII control characters are to be avoided.

If you need automatic accounts to log in (legitimate "bots") then they should not have passwords, instead you should provide an authentication API with an access token and a secret key, that the bot can use to make API calls to do whatever it needs to do on your application. This is the industry standard and you would do well to follow it instead of creating ad-hoc binary password schemes.

Generally it is good practice to separate human users and automated scripts/bots, even if just for auditing purposes.

So, in short:


don't give automatic accounts passwords, give them API keys that can easily be tracked and revoked; bots are not humans, they do not behave like humans, and they cannot be treated as humans; treating them the same in your authentication logic is a severe category error;
do validate passwords entered by the user, and accept general UTF-8 characters, but reject obviously invalid characters (control characters), for anything else let users sort themselves out with the "forgot password" feature if they mess up;
in the future, don't work around ridiculous implementation bugs (such as your bcrypt function not accepting null bytes) by modifying your fundamental design and core application assumptions; fix your implementation instead!!