What version of Go are you using (go version)?

$ go version
go version devel go1.19-914195c132 Thu Mar 10 21:10:30 2022 +0000 darwin/amd64

Does this issue reproduce with the latest release?

At least current gotip.

What operating system and processor architecture are you using (go env)?

$ go env
N/A

What did you do?

I created a workspace using go work init a level below an existing module and then tried to run my existing module.
e.g. with:

-- foo/go.mod --
module foo

go 1.19
-- foo/main.go --
package main

func main() {}
-- go.work --
go 1.19

Inside of foo I ran:

$ go build .
go: no modules were found in the current workspace; see 'go help work'
$ go run .
go: no modules were found in the current workspace; see 'go help work'
$ go list -m all
go: cannot match "all": go.mod file not found in current directory or any parent directory; see 'go help modules'

What did you expect to see? / What did you see instead?

Since my module isn't a part of the workspace I expect it to run/build.
The error messages for build and run do point me in the right direction, but if I instead have a slightly different scenario where I just forget (or don't know that I should) add foo to my go.work file:

-- a/a.go --
package a

const A = 1
-- a/go.mod --
module a

go 1.19
-- b/b.go --
package b

const B = 2
-- b/go.mod --
module b

go 1.19
-- foo/go.mod --
module foo

go 1.19
-- foo/main.go --
package main

import (
	"a"
	"b"
)

func main() {
	println(a.A)
	println(b.B)
}
-- go.work --
go 1.19

use (
	./a
	./b
)

Then gopls actually works as expected (can dereference a.A in main.go etc), but building/running fails with a more confusing error message:

$ go run .
go: no packages loaded from .
$ go list -m all
a
b
$ go build .
directory . outside modules listed in go.work or their selected dependencies

Again I would expect it to not use workspace mode since the module itself isn't a part of the workspace (or drop an error and refuse to build/run).
The benefits of not using workspace mode in this case would be that the tooling (e.g. gopls) wouldn't resolve the packages so it gets obvious to the user that something is wrong.
On the other side, if the workspace for example replace a version, things gets more subtle and that speaks in favor of erroring out.