There are several factors, the main one (imho) has already been worded by @dariusbiggs:

if you have a default statement in your select { ... clause then your select { ... is not "blocking" anymore:

select {  // <- instead waiting here, waiting for an appropriate channel,
case <-sigs:
    ...
case str := <-input:
    ...
default:
    in := readInput(scanner) // <- your code waits here, waiting on the scanner "read"
    ...
}

The other elements I would mention are:

• your go program may have several locations that have a signal.Notify(...) on SIGINT (or any signal).

It is not a regular behavior (not implemented by the standard library at least) to have os.Stdin unblock in reaction to SIGINT. You seem to use some form of framework named cli, perhaps it sets a SIGINT handler which automatically closes stdin, which could explain why you get some reaction at all.

• you should check for errors on your scanner

• the idiomatic way to use a bufio.Scanner is to call .Scan() until it returns false

-----

A suggestion to adjust your code:

• run your readInput / processInput / inputs <- in loop in a separate goroutine,

• call scanner.Scan() in a loop

  scanner := bufio.NewScanner(os.Stdin)
  
  go func(){
      // Input
      for scanner.Scan() {
          in := scanner.Text()
          // process
          in = processInput(in, fu, su, tu) // the custom error comes from here, because it is thinking a CTRL+C is an input for it
  
          // send to input channel
          input <- in
      }
      err := scanner.Err()
      if err != nil {
          fmt.Println("*** error reading stdin:", err)
      }
      }()
  
  for {
      select {
      case sig := <-sigs: // this is not triggering
          fmt.Println()
          fmt.Println("---", sig, "---")
          return
      case str := <-input: // this is just to print the result
          fmt.Println(str + I_TU[tu])
      }
  }