bug: `celestia light init` and `light start` always run `bridge init` logic first (unintended behavior)

[jcstein]

Celestia Node version

v0.22.2-mocha

OS

MacOS, docker is...OS: Debian GNU/Linux 12 (bookworm) via Docker base image

Install tools

Docker Compose
Compose file uses celestia light init and light start in separate containers with shared volume

This example can test the MVP of issue:

services:
  celestia-node-init:
    image: ghcr.io/celestiaorg/celestia-node:v0.22.2-mocha
    container_name: celestia-node-init
    command:
      - celestia
      - light
      - init
      - --p2p.network
      - mocha
      - --node.store
      - /home/celestia/.celestia-light-mocha-4
    volumes:
      - ./celestia-test:/home/celestia

Others

• Using --node.store /home/celestia/.celestia-light-mocha-4 to separate light node config
• Volume is mounted at /home/celestia in both init and start
• No changes to config.toml or runtime flags aside from standard startup options

Steps to reproduce it

1. Use the official Docker image ghcr.io/celestiaorg/celestia-node:v0.22.2-mocha
2. Run the following as part of a Docker Compose config:

command: [
  "celestia", "light", "init",
  "--p2p.network", "mocha",
  "--node.store", "/home/celestia/.celestia-light-mocha-4"
]

3. And later run,

command: [
  "celestia", "light", "start",
  "--p2p.network", "mocha",
  "--core.ip", "rpc-mocha.pops.one",
  "--core.port", "9090",
  "--rpc.addr", "0.0.0.0",
  "--node.store", "/home/celestia/.celestia-light-mocha-4"
]

Expected result

Only the light node is initialized — no bridge logic should be run, no bridge config or keys should appear in /home/celestia.

Actual result

Before executing the light subcommand, the binary logs indicate that it first runs celestia bridge init and writes a config.toml and key to /home/celestia

This results in the /home/celestia volume containing a mix of bridge and light node configs.

Relevant log output

2025-05-29 19:18:35.545 | Initializing Celestia Node with command:
2025-05-29 19:18:35.545 | celestia bridge init --p2p.network mocha --rpc.addr=0.0.0.0 --gateway.addr=0.0.0.0
2025-05-29 19:18:35.578 | 2025-05-29T10:18:35.578Z	WARN	module/gateway	gateway/flags.go:47	custom address or port provided without enabling gateway, setting config values
2025-05-29 19:18:35.578 | 2025-05-29T10:18:35.578Z	WARN	module/pruner	pruner/flags.go:51	WARNING: Node is now running in ARCHIVAL mode.
2025-05-29 19:18:35.578 | PRUNING mode will become the default for all nodes.
2025-05-29 19:18:35.578 | If you want to retain history beyond the sampling window, please pass the --archival flag.
2025-05-29 19:18:35.578 | 2025-05-29T10:18:35.578Z	INFO	node	nodebuilder/init.go:31	Initializing Bridge Node Store over '/home/celestia'
2025-05-29 19:18:35.580 | 2025-05-29T10:18:35.579Z	INFO	node	nodebuilder/init.go:64	Saved config	{"path": "/home/celestia/config.toml"}
2025-05-29 19:18:35.580 | 2025-05-29T10:18:35.579Z	INFO	node	nodebuilder/init.go:66	Accessing keyring...
2025-05-29 19:18:35.581 | 2025-05-29T10:18:35.581Z	WARN	node	nodebuilder/init.go:196	Detected plaintext keyring backend. For elevated security properties, consider using the `file` keyring backend.
2025-05-29 19:18:35.582 | 2025-05-29T10:18:35.582Z	INFO	node	nodebuilder/init.go:211	NO KEY FOUND IN STORE, GENERATING NEW KEY...	{"path": "/home/celestia/keys"}
2025-05-29 19:18:35.592 | 
2025-05-29 19:18:35.592 | NAME: my_celes_key
2025-05-29 19:18:35.592 | ADDRESS: celestia12qv2ejw8py60ewuar3lg7vvzv2u0e2urk7uxdv
2025-05-29 19:18:35.592 | 2025-05-29T10:18:35.592Z	INFO	node	nodebuilder/init.go:216	NEW KEY GENERATED...
2025-05-29 19:18:35.592 | 2025-05-29T10:18:35.592Z	INFO	node	nodebuilder/init.go:73	Node Store initialized
2025-05-29 19:18:35.592 | MNEMONIC (save this somewhere safe!!!): 
2025-05-29 19:18:35.592 | never gonna give you up let you down run around desert you never gonna make you cry say goodbye never gonna tell a lie and hurt you
2025-05-29 19:18:35.592 | 
2025-05-29 19:18:35.599 | 
2025-05-29 19:18:35.599 | 
2025-05-29 19:18:35.599 | Starting Celestia Node with command:
2025-05-29 19:18:35.599 | celestia light init --p2p.network mocha --node.store /home/celestia/.celestia-light-mocha-4
2025-05-29 19:18:35.599 | 
2025-05-29 19:18:35.629 | 2025-05-29T10:18:35.629Z	INFO	node	nodebuilder/init.go:31	Initializing Light Node Store over '/home/celestia/.celestia-light-mocha-4'
2025-05-29 19:18:35.631 | 2025-05-29T10:18:35.631Z	INFO	node	nodebuilder/init.go:64	Saved config	{"path": "/home/celestia/.celestia-light-mocha-4/config.toml"}
2025-05-29 19:18:35.631 | 2025-05-29T10:18:35.631Z	INFO	node	nodebuilder/init.go:66	Accessing keyring...
2025-05-29 19:18:35.632 | 2025-05-29T10:18:35.632Z	WARN	node	nodebuilder/init.go:196	Detected plaintext keyring backend. For elevated security properties, consider using the `file` keyring backend.
2025-05-29 19:18:35.633 | 2025-05-29T10:18:35.633Z	INFO	node	nodebuilder/init.go:211	NO KEY FOUND IN STORE, GENERATING NEW KEY...	{"path": "/home/celestia/.celestia-light-mocha-4/keys"}
2025-05-29 19:18:35.642 | 2025-05-29T10:18:35.642Z	INFO	node	nodebuilder/init.go:216	NEW KEY GENERATED...
2025-05-29 19:18:35.642 | 2025-05-29T10:18:35.642Z	INFO	node	nodebuilder/init.go:73	Node Store initialized
2025-05-29 19:18:35.642 | 
2025-05-29 19:18:35.642 | NAME: my_celes_key
2025-05-29 19:18:35.642 | ADDRESS: celestia14dkermkuy3cpnf96rs2gmdze0ahcxze26cy7mq
2025-05-29 19:18:35.642 | MNEMONIC (save this somewhere safe!!!): 
2025-05-29 19:18:35.642 | never gonna give you up let you down run around desert you never gonna make you cry say goodbye never gonna tell a lie and hurt you
2025-05-29 19:18:35.642 |

Is the node "stuck"? Has it stopped syncing?

No — the node does start and sync correctly, but the pre-run bridge init is incorrect and causes confusion.

Notes

This behavior appears on both light init and light start and makes volume-based automation much harder. It results in a polluted config directory and the risk of fallback to unintended node types. This may be a bug in how the binary bootstraps itself internally before subcommand execution.

Found when testing out here: https://gist.github.com/jcstein/6407ed9bc1368416eab2660866f460dd

[jcstein]

While helping someone debug a related issue, we observed that celestia light init and light start commands were consistently preceded by a bridge init, even though the commands explicitly invoked light.

This behavior occurred in both:

• A multi-service Docker Compose setup with separate init and start containers, and
• A single-container setup using a shell script that conditionally runs light init and then light start

In both cases, logs show the CLI first executes bridge init, initializing a bridge store and keyring at /home/celestia, before proceeding to light init and creating a separate store under .celestia-light-mocha-4.

It appears this behavior is internal to the celestia CLI and happens regardless of the subcommand.

[rose2221]

would like to work on it! Could you assign it to me?