My first instinct on this (and keep in mind that this is before Coffee #1) is that you could simply add an extra condition to the heuristic.  Say a grid square is only reachable if there is enough "space" for the unit to fit.  You'd add one more parameter to your search, but provided that your units are all using rectangular areas this shouldn't be too hard.  To summerize, simply check at each grid point if there is a axb grid of space around the central point you are trying to reach.  If there is, then it's reachable (assuming it was reachable in the first place) and continue as normal, if it's not, then return infinity, or whatever method you are using to denote a grid square unreachable in your implementation.

Am I making sense?

When a player crouches, another, smaller bounding box is used for collision detection calculations. This does not really provide a problem for AAS though. Multiple sized bounding boxes can be compiled into the same BSP tree. For each bounding box a set of brushes is created and expanded for that bounding box. CSG operations are only performed on and between brushes that are expanded for the same bounding box. From all sets of expanded brushes one BSP tree is created. After creating the BSP tree it can easily be determined which bounding box(es) can move in each convex sub-space represented by a leaf node. When a convex sub-space represented by a leaf node contains no expanded solid brushes then all bounding boxes can move around there. When a convex sub-space represented by a leaf node contains one or more solid brushes expanded for a certain bounding box, then that bounding box cannot move around there.

I'm probably only restating advice someone else already gave, but:

some part of your pathfinding (undirected graph search algorithm) is devoted to expanding on a candidate solution and queuing each of the 'child solutions' reached from that candidate.  That is, perhaps you have a priority queue of candidate solutions and you pop off the best-looking solution and examine it.  Based on that solution you create all possible "next step" solutions that go one step farther from the solution you have already.  This is how undirected graph search algorithms work, and you're already doing this.

Find that part of your code.  Some logic in that part must be devoted to identifying collisions and disallowing candidate solutions that cause collisions.  For example if your candidate path is right next to a wall, you don't try to expand solutions that take you through the wall.

You should modify that part of your code and have it check for collisions which assume a larger body size.  If you are on a grid of squares and your piece is 1x1 wide -- a case you've already solved -- you simply check for collisions in any of the four or eight neighboring squares, checking one square per candidate solution.  If your piece is 3x3 wide, then for each candidate solution you must check the nine squares your piece will occupy.  If 5x5 wide then for each candidate solution check the fifteen squares your piece will occupy.

That should automatically eliminate candidate solutions that try to take your piece through a gap too small to fit thorugh.  Your search algorithm will start to consider those solutions, realize that there are no valid moves through the gap because the gap is too small to fit through, and will eventually settle on an optimal solution.