What causes "panic(err)" in direnv/direnv?

Use Parse and handle the error instead of MustParse when input is not statically valid

panic(err)

Error message

panic(err)

What it means

MustParse is the panic-on-error variant of dotenv.Parse; when the input contains any parse failure (invalid line, unclosed quote, etc.) it panics with the wrapped error instead of returning it. The error is never a distinct type — it is whatever Parse returned.

Source

Thrown at pkg/dotenv/parse.go:126

		key := match[1]
		value := match[2]

		parseValue(key, value, dotenv)
	}

	// If we end with an unclosed multi-line value, return an error
	if inMultiline {
		return nil, fmt.Errorf("unclosed quoted value in .env file")
	}

	return dotenv, nil
}

// MustParse works the same as Parse but panics on error
func MustParse(data string) map[string]string {
	env, err := Parse(data)
	if err != nil {
		panic(err)
	}
	return env
}

func parseValue(key string, value string, dotenv map[string]string) {
	if len(value) <= 1 {
		dotenv[key] = value
		return
	}

	singleQuoted := false

	if value[0:1] == "'" && value[len(value)-1:] == "'" {
		// single-quoted string, do not expand
		singleQuoted = true
		value = value[1 : len(value)-1]
	} else if value[0:1] == `"` && value[len(value)-1:] == `"` {
		value = value[1 : len(value)-1]

View on GitHub (pinned to b00e451f54)

Solutions

Use Parse and handle the error instead of MustParse when input is not statically valid
Validate/fix the input string before calling MustParse
In tests, use recover() if intentionally asserting the panic

Example fix

// before
env := dotenv.MustParse(userInput)
// after
env, err := dotenv.Parse(userInput)
if err != nil {
    return fmt.Errorf("bad .env: %w", err)
}

Defensive patterns

Strategy: try-catch

Try / catch

func safeMustParse(s string) (m map[string]string) {
    defer func() { if r := recover(); r != nil { m = nil } }()
    return dotenv.MustParse(s)
}

Prevention

Prefer Parse over MustParse for any non-constant input
Only call MustParse on literals or test fixtures known to be valid
Wrap MustParse with recover() in library code
Keep test fixtures linted so MustParse never panics unexpectedly

When it happens

Trigger: Any call to MustParse with malformed .env content, directly in tests (TestFailingMustParse) or via test helpers that assert valid fixtures.

Common situations: Unit tests feeding intentionally invalid data to verify panic behavior; developers using MustParse in non-test code with user-supplied or hand-edited content; fixtures drifted out of valid syntax.

Related errors

AI-assisted analysis of direnv/direnv@b00e451f54 (2026-09-05). Data as JSON: /api/errors/d57240c224cd3149. Report an issue: GitHub.