c# Ignoring conditional statement?

I'm going to assume that digBike is a method that starts the coroutine you mention.

This may be a poor attempt at humor, that I can't resist whenever I encounter a question like this, which also conveys a bit of wisdom accumulated in several decades of programming, I've never seen a computer ignore an "if" statement. In my first few years I would have sworn it was ignoring me, just for spite. I can't count how many times I just "knew" the computer was failing at basic math, or ignoring some obvious logical test, but alas it has never been true. Under the hood these statements translate into just a few machine language instructions, so it is very close to direct action and control at the CPU, and if that only worked occasionally the entire operating system would never function. It has always been something else. So, like it was for me in those first few years, whenever you have that sense that the computer is just plain ignoring you, it isn't. It is something else.

Take this portion of your code to study:

          if (other.gameObject.tag == "stuffBike")
          {
              if (canDiveBike == true)
              { ///////
                  sound.SetActive(true);
              }//////
                  if (Input.GetKeyDown(KeyCode.E))
                  {
                      digBike();
                  }
             
          }

This section has an outer "if" clause which only executes when other.gameObject.tag == "stuffBike". All else between the brackets associated with this clause executes only when that tag matches. However, look at the next two "if" clauses. You mentioned the bool, which I believe is canDiveBike == true. When that is true there is a call to sound.SetActive(true), but that is all that applies to the condition that canDiveBike is true. The next test, a check for the "E" key, is outside the brackets enclosing the block of code associated with the test for canDiveBike. This second test is performed no matter what the state of canDiveBike. In this second clause, for KeyCode.E, if the key is down there will be a call to digBike (which I assume launches your coroutine), and that test passes no matter what canDiveBike may be. If you want this key tested and digBike called only when canDiveBike is true, that code (the if( GetKeyCode...)) must be inside the brackets associated with the "if ( canDiveBike == true )".

There's another place you show where digBike is called, in the OnTriggerStay method. Here, too, there's no check for canDiveBike, so there's a second place where digBike can be called no matter what the state of canDiveBike may be, as long as the tag on "other" is "stuffBike" and the "E" key is held down. You would have to also add the test for canDiveBike, either just before you call digBike or as a third clause in the "if" statement in this method.

With that said, if I assume that digBike is a method which starts the coroutine, you could move the test for canDiveBike into that method (only start the coroutine when it is true), and therefore wouldn't have to concern yourself with ensuring that check is made in two separate locations like you're doing. For that matter, if the checks for E and "stuffBike" are also required, you could put those in digBike, and just rely on calling digBike without any test, so that digBike performs all 3 tests no matter how many times you call digBike. This latter point is about organization of code. Any time you find yourself repeating things, you're leaving behind the chance that you also have repeated locations to fix the same bug. Wrap those repeated things into a method (functions in other language), so there is only 1 place that work is done, only one place to debug and fix if it's incorrect.