[Bug]: CLI prints DEBUG "deepcode_config.json not found... skipping layer" noise - setup_logging() never called by CLI entrypoints

[AnaheimEX]

Bug description

The interactive CLI prints DEBUG noise on every config load:

2026-08-07 07:03:11.495 | DEBUG    | core.config:_load_raw:577 - deepcode_config.json not found at /Users/anaheim/deepcode_config.json; skipping layer

The same line appears twice per turn start and around /effort etc. It happens in every directory that has no project-level deepcode_config.json (the common case — the home layer at ~/.deepcode/deepcode_config.json loads fine).

Root cause

setup_logging() in core/observability/bus.py is never called by any CLI entrypoint — it is only defined, never invoked (grep for setup_logging( finds no callers in cli/ or core/). Therefore loguru keeps its built-in default sink (stderr, DEBUG level), and every missing config layer probed by _load_raw() (core/config.py:577) prints a DEBUG line.

Additionally:

• LoggerConfig (core/config.py, incl. logger.level) has no consumer — nothing reads the config's logger section to configure loguru, so users cannot silence this via ~/.deepcode/deepcode_config.json.
• DEEPCODE_LOG_LEVEL env var is only read in cli/mcp_server.py (MCP server only), not the main CLI.
• The Desktop app is unaffected (it wires logging.basicConfig in app_server/__main__.py).

Expected behavior

The CLI should call setup_logging(load_config().logger) at startup (TUI and loop entrypoints), defaulting to INFO, and respect logger.level from the config. Note the ordering matters: setup_logging must run before load_config(), because load_config() itself emits the DEBUG lines.

Environment

• deepcode 2.0.0 (via uv tool install deepcode-hku)
• macOS arm64
• Reproduced with the interactive TUI (deepcode) and in loop mode

Suggested fix

# in cli/tui/app.py main() and cli/loop_cli.py main(), before anything loads config:
from core.config import LoggerConfig, load_config
from core.observability import setup_logging

setup_logging(LoggerConfig(transports=["console"]))
cfg = load_config()
if cfg.logger.level.upper() != "INFO":
    setup_logging(LoggerConfig(level=cfg.logger.level, transports=["console"]), force=True)

[Zongwei9888]

Thanks — this is an unusually good report. You found the root cause, the exact call site, and the ordering trap that makes the obvious fix not work. All three of your claims check out:

• setup_logging() is never called. Every occurrence in the tree is a definition, a re-export or a docstring. Inspecting loguru's handler table after importing the CLI confirms it: one sink, id 0, level 10, a StreamSink on stderr — the built-in default, still in place.
• The noise is core/config.py:_load_raw, once per absent config layer.
• LoggerConfig.level had no consumer, so there was no way to turn it down from the config either.

All three follow from that one missing call.

Your point about ordering was the important one. setup_logging(load_config().logger) cannot work, because reading the config is itself one of the things that logs. The fix installs a quiet default first and applies the configured level afterwards, only when it differs — essentially the shape you sketched.

One thing done differently: the call went into deepcode.main() rather than the TUI and loop entrypoints. setup.py declares a single console_scripts entry (deepcode=deepcode:main) and that function dispatches all ten subcommands, so one call covers exec, session, skill, provider, schedule, automation and the rest as well. Adding it per-entrypoint would have meant the same block ten times over, with the eleventh subcommand forgetting it.

DEEPCODE_LOG_LEVEL now works for the main CLI too, not just deepcode mcp, and short-circuits the config entirely — which makes it usable for debugging config loading itself.

Verified from a directory with no project config:

	sink level	load_config()
before	10 (loguru default)	prints the DEBUG line
after, default	20	silent
after, DEEPCODE_LOG_LEVEL=DEBUG	10	prints it again

Fixed in #169.