wp db commands fail when DB_XXXXX environment variables are set up by direnv

[kauhat]

Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

---

Hi,

this is a bit of a weird issue that I've been running into for a while. I'm working on a Roots Bedrock based site which configures WordPress via a .env file. I had a direnv .envrc file sourcing the .env, which looked like this:

layout php
dotenv .env

this populated my shell environment with variables such as DB_NAME, DB_PASSWORD, WP_ENV, etc. perhaps this was bad practice on my part, but I'm working within my development environment. these are the same credentials used by my development WordPress installation.

when running the wp db commands, I was running into strange errors:

$ cd ~/Dev/example
/home/jack/Dev/example
direnv: loading ~/Dev/example/.envrc
direnv: export +ACF_PRO_KEY +AUTH_KEY +AUTH_SALT +DB_HOST +DB_NAME +DB_PASSWORD +DB_USER +GRAVITY_FORMS_KEY +LOGGED_IN_KEY +LOGGED_IN_SALT +NONCE_KEY +NONCE_SALT +SECURE_AUTH_KEY +SECURE_AUTH_SALT +WP_DEBUG_LOG +WP_ENV +WP_HOME +WP_SITEURL ~PATH

$ wp db check
mysqlcheck: [ERROR] unknown variable 'pass='.

$ wp db cli
mysql: [ERROR] unknown variable 'pass='.

$ wp db export
mysqldump: [ERROR] unknown variable 'pass='.

$ wp db tables
Error: Error establishing a database connection.

after unseting the DB_* environment variables, all of the wp db commands work as normal.

$ compgen -v | grep DB_
DB_HOST
DB_NAME
DB_PASSWORD
DB_USER

$ wp db check
mysqlcheck: [ERROR] unknown variable 'pass='.

$ unset DB_HOST DB_NAME DB_PASSWORD DB_USER

$ wp db check
example.wp_actionscheduler_actions OK
example.wp_actionscheduler_claims OK
example.wp_actionscheduler_groups OK
example.wp_actionscheduler_logs   OK
...
example.wp_yoast_indexable_hierarchy OK
example.wp_yoast_migrations       OK
example.wp_yoast_primary_term     OK
example.wp_yoast_seo_links        OK
Success: Database checked.

$ wp db cli
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 47
Server version: 8.0.46-0ubuntu0.24.04.3 (Ubuntu)

Copyright (c) 2000, 2026, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> ^C

Bye


$ wp db tables
wp_actionscheduler_actions
wp_actionscheduler_claims
wp_actionscheduler_groups
wp_actionscheduler_logs
...
wp_termmeta
wp_terms
wp_usermeta
wp_users

however, this issue is not present when when variables are unset and then sourced again.

this has me stumped, and as such I can't suggest a fix. potentially it's out of scope for this project, however I've been using direnv in my development environments for years and have never encountered an issue like this before. Other parts of WP CLI appear to be working as expected.

$ cd ~/Dev/example
/home/jack/Dev/example
direnv: loading ~/Dev/example/.envrc
direnv: export +ACF_PRO_KEY +AUTH_KEY +AUTH_SALT +DB_HOST +DB_NAME +DB_PASSWORD +DB_USER +GRAVITY_FORMS_KEY +LOGGED_IN_KEY +LOGGED_IN_SALT +NONCE_KEY +NONCE_SALT +SECURE_AUTH_KEY +SECURE_AUTH_SALT +WP_DEBUG_LOG +WP_ENV +WP_HOME +WP_SITEURL ~PATH

$ wp db check
mysqlcheck: [ERROR] unknown variable 'pass='.

# this should override the direnv sourced vars?
$ source .env

# but that still doesn't work
$ wp db check
mysqlcheck: [ERROR] unknown variable 'pass='.

# I have to fully unset the vars?
$ unset DB_HOST DB_NAME DB_PASSWORD DB_USER

$ source .env

$ compgen -v | grep DB_
DB_HOST
DB_NAME
DB_PASSWORD
DB_USER

$ wp db check
example.wp_actionscheduler_actions OK
example.wp_actionscheduler_claims OK
example.wp_actionscheduler_groups OK
example.wp_actionscheduler_logs   OK
...
example.wp_yoast_indexable_hierarchy OK
example.wp_yoast_migrations       OK
example.wp_yoast_primary_term     OK
example.wp_yoast_seo_links        OK
Success: Database checked.

---

I've encountered this on Ubuntu 24.04 / PHP 8.4 in Fish and Bash shells.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04.4 LTS
Release:        24.04
Codename:       noble

$ apt list --installed | grep -E 'mysql|php|direnv|bash|fish'

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

bash-completion/noble,now 1:2.11-8 all [installed]
bash/noble,now 5.2.21-2ubuntu4 amd64 [installed]
direnv/noble-updates,noble-security,now 2.32.1-2ubuntu0.24.04.3 amd64 [installed]
fish/noble,now 4.8.1-1~noble amd64 [installed]
libapache2-mod-php8.4/now 8.4.7-1+ubuntu20.04.1+deb.sury.org+1 amd64 [installed,local]
libapache2-mod-php/now 2:8.4+96+ubuntu20.04.1+deb.sury.org+1 all [installed,local]
libdbd-mysql-perl/noble,now 4.052-1ubuntu3 amd64 [installed,auto-removable]
libmysqlclient21/noble-updates,noble-security,now 8.0.46-0ubuntu0.24.04.3 amd64 [installed]
mysql-client-8.0/noble-updates,noble-security,now 8.0.46-0ubuntu0.24.04.3 amd64 [installed,automatic]
mysql-client-core-8.0/noble-updates,noble-security,now 8.0.46-0ubuntu0.24.04.3 amd64 [installed,automatic]
mysql-client/noble-updates,noble-security,now 8.0.46-0ubuntu0.24.04.3 all [installed]
mysql-common/noble,now 5.8+1.1.0build1 all [installed,automatic]
mysql-server-8.0/noble-updates,noble-security,now 8.0.46-0ubuntu0.24.04.3 amd64 [installed,automatic]
mysql-server-core-8.0/noble-updates,noble-security,now 8.0.46-0ubuntu0.24.04.3 amd64 [installed,automatic]
mysql-server/noble-updates,noble-security,now 8.0.46-0ubuntu0.24.04.3 all [installed]
php-bcmath/now 2:8.4+96+ubuntu20.04.1+deb.sury.org+1 all [installed,local]
php-cli/now 2:8.4+96+ubuntu20.04.1+deb.sury.org+1 all [installed,local]
php-common/now 2:96+ubuntu20.04.1+deb.sury.org+1 all [installed,local]
php-curl/now 2:8.4+96+ubuntu20.04.1+deb.sury.org+1 all [installed,local]
php-dev/now 2:8.4+96+ubuntu20.04.1+deb.sury.org+1 all [installed,local]
php-fpm/now 2:8.4+96+ubuntu20.04.1+deb.sury.org+1 all [installed,local]
php-gd/now 2:8.4+96+ubuntu20.04.1+deb.sury.org+1 all [installed,local]
php-intl/now 2:8.4+96+ubuntu20.04.1+deb.sury.org+1 all [installed,local]
php-json/now 2:8.4+96+ubuntu20.04.1+deb.sury.org+1 all [installed,local]
php-mbstring/now 2:8.4+96+ubuntu20.04.1+deb.sury.org+1 all [installed,local]
php-mysql/now 2:8.4+96+ubuntu20.04.1+deb.sury.org+1 all [installed,local]
php-pear/now 1:1.10.16+submodules+notgz-2+ubuntu20.04.1+deb.sury.org+1 all [installed,local]
php-sqlite3/now 2:8.4+96+ubuntu20.04.1+deb.sury.org+1 all [installed,local]
php-tokenizer/noble,now 1.2.3-1 all [installed]
php-xml/now 2:8.4+96+ubuntu20.04.1+deb.sury.org+1 all [installed,local]
php-zip/now 2:8.4+96+ubuntu20.04.1+deb.sury.org+1 all [installed,local]
php8.4-bcmath/now 8.4.7-1+ubuntu20.04.1+deb.sury.org+1 amd64 [installed,local]
php8.4-cli/now 8.4.7-1+ubuntu20.04.1+deb.sury.org+1 amd64 [installed,local]
php8.4-common/now 8.4.7-1+ubuntu20.04.1+deb.sury.org+1 amd64 [installed,local]
php8.4-curl/now 8.4.7-1+ubuntu20.04.1+deb.sury.org+1 amd64 [installed,local]
php8.4-dev/now 8.4.7-1+ubuntu20.04.1+deb.sury.org+1 amd64 [installed,local]
php8.4-fpm/now 8.4.7-1+ubuntu20.04.1+deb.sury.org+1 amd64 [installed,local]
php8.4-gd/now 8.4.7-1+ubuntu20.04.1+deb.sury.org+1 amd64 [installed,local]
php8.4-intl/now 8.4.7-1+ubuntu20.04.1+deb.sury.org+1 amd64 [installed,local]
php8.4-mbstring/now 8.4.7-1+ubuntu20.04.1+deb.sury.org+1 amd64 [installed,local]
php8.4-mysql/now 8.4.7-1+ubuntu20.04.1+deb.sury.org+1 amd64 [installed,local]
php8.4-opcache/now 8.4.7-1+ubuntu20.04.1+deb.sury.org+1 amd64 [installed,local]
php8.4-readline/now 8.4.7-1+ubuntu20.04.1+deb.sury.org+1 amd64 [installed,local]
php8.4-sqlite3/now 8.4.7-1+ubuntu20.04.1+deb.sury.org+1 amd64 [installed,local]
php8.4-xml/now 8.4.7-1+ubuntu20.04.1+deb.sury.org+1 amd64 [installed,local]
php8.4-zip/now 8.4.7-1+ubuntu20.04.1+deb.sury.org+1 amd64 [installed,local]
php8.4/now 8.4.7-1+ubuntu20.04.1+deb.sury.org+1 all [installed,local]
php/now 2:8.4+96+ubuntu20.04.1+deb.sury.org+1 all [installed,local]
pkg-php-tools/noble,now 1.44 all [installed,automatic]

Workarounds

Disable dotenv loading in .envrc.

dotenv .env

Or unset the DB_* variables in each shell session.

Bash shell

unset DB_HOST DB_NAME DB_PASSWORD DB_USER

Fish shell

set -e DB_HOST DB_NAME DB_PASSWORD DB_USER

[kauhat]

values for the variables are identical throughout, hashes match:

$ cd example/
direnv: loading ~/Dev/example/.envrc
direnv: export +ACF_PRO_KEY +AUTH_KEY +AUTH_SALT +DB_HOST +DB_NAME +DB_PASSWORD +DB_USER +GRAVITY_FORMS_KEY +LOGGED_IN_KEY +LOGGED_IN_SALT +NONCE_KEY +NONCE_SALT +SECURE_AUTH_KEY +SECURE_AUTH_SALT +WP_DEBUG_LOG +WP_ENV +WP_HOME +WP_SITEURL ~PATH

# Environment vars set up by direnv...
$ echo -n "$DB_NAME $DB_HOST $DB_USER $DB_PASSWORD" | md5sum 
d3b46ef9e63e4a9a5828268854046d68  -

$ wp db check
mysqlcheck: [ERROR] unknown variable 'pass='.

# After attempted override with source command...
$ source .env

$ echo -n "$DB_NAME $DB_HOST $DB_USER $DB_PASSWORD" | md5sum 
d3b46ef9e63e4a9a5828268854046d68  -

$ wp db check
mysqlcheck: [ERROR] unknown variable 'pass='.

# Unset and reload variables...
$ unset DB_NAME DB_HOST DB_USER DB_PASSWORD 

$ source .env

$ echo -n "$DB_NAME $DB_HOST $DB_USER $DB_PASSWORD" | md5sum 
d3b46ef9e63e4a9a5828268854046d68  -

$ wp db check
example.wp_actionscheduler_actions OK
example.wp_actionscheduler_claims OK
example.wp_actionscheduler_groups OK
example.wp_actionscheduler_logs   OK
example.wp_commentmeta            OK
example.wp_comments               OK
example.wp_gf_draft_submissions   OK
example.wp_gf_entry               OK
example.wp_gf_entry_meta          OK
example.wp_gf_entry_notes         OK
example.wp_gf_form                OK

how strange! as I mentioned this issue may be external to WP CLI, but it's been bugging me for months. I hope this information helps someone, some day.

[swissspidy]

This sounds like a bug in Bedrock. Are you on v1.29.0 or newer? See roots/bedrock#800