Description
Today, the runtime log-level precedence is CLI > Config > Agent. When either --LogLevel is passed on the CLI or runtime.telemetry.log-level is set in config, MCP logging/setLevel requests are silently rejected and the agent has no way to change the level at runtime.
Per the team's discussion locked on 5/1 (Jerry, confirmed by Aniruddh), the intended precedence is Agent > CLI > Config:
- If nothing is set anywhere → defaults (Production = Error, Development = Debug;
--mcp-stdio = None).
- Config sets the default level.
- CLI overrides Config.
- Agent (
logging/setLevel) overrides CLI and Config.
Expected
- With
dab start --LogLevel Error running, an MCP logging/setLevel debug request takes effect and subsequent logs include Debug entries.
- With
runtime.telemetry.log-level: error in config, an MCP logging/setLevel debug request takes effect.
- CLI continues to override Config when the agent doesn't speak up.
Actual
DynamicLogLevelProvider.UpdateFromMcp returns false when IsCliOverridden || IsConfigOverridden, so the level never changes.
- Unit tests
"CLI override blocks MCP change" and "Config override blocks MCP change" lock this behavior.
Repro
dab start --LogLevel Error --mcp-stdio (or any host with --LogLevel).
- Send MCP request:
{"jsonrpc":"2.0","method":"logging/setLevel","params":{"level":"debug"},"id":1}
- Trigger any operation that would emit Debug logs.
- Observe: no Debug entries appear; the agent's request was silently ignored.
Proposed fix
- Remove the CLI / Config early-rejects in
DynamicLogLevelProvider.UpdateFromMcp.
- Add
IsAgentOverridden and have UpdateFromRuntimeConfig skip when it's set (so hot-reload doesn't clobber the agent).
- Emit an
Information log line when the agent successfully changes the level, so operators can see the override.
- Update existing tests to reflect Agent > CLI > Config; add a hot-reload-after-agent test and an agent-beats-CLI test.
- Manual:
dab start --mcp-stdio --LogLevel Error, send logging/setLevel debug, verify logs flow at Debug.
Out of scope
- CLI > Config rule (unchanged — CLI still beats Config when the agent doesn't speak up).
- Default levels (Production = Error, Development = Debug,
--mcp-stdio = None — all unchanged).
- Agent "release" of override (no team ask yet — call as a follow-up if reviewers raise it).
Description
Today, the runtime log-level precedence is CLI > Config > Agent. When either
--LogLevelis passed on the CLI orruntime.telemetry.log-levelis set in config, MCPlogging/setLevelrequests are silently rejected and the agent has no way to change the level at runtime.Per the team's discussion locked on 5/1 (Jerry, confirmed by Aniruddh), the intended precedence is Agent > CLI > Config:
--mcp-stdio= None).logging/setLevel) overrides CLI and Config.Expected
dab start --LogLevel Errorrunning, an MCPlogging/setLevel debugrequest takes effect and subsequent logs include Debug entries.runtime.telemetry.log-level: errorin config, an MCPlogging/setLevel debugrequest takes effect.Actual
DynamicLogLevelProvider.UpdateFromMcpreturnsfalsewhenIsCliOverridden || IsConfigOverridden, so the level never changes."CLI override blocks MCP change"and"Config override blocks MCP change"lock this behavior.Repro
dab start --LogLevel Error --mcp-stdio(or any host with--LogLevel).{"jsonrpc":"2.0","method":"logging/setLevel","params":{"level":"debug"},"id":1}Proposed fix
DynamicLogLevelProvider.UpdateFromMcp.IsAgentOverriddenand haveUpdateFromRuntimeConfigskip when it's set (so hot-reload doesn't clobber the agent).Informationlog line when the agent successfully changes the level, so operators can see the override.dab start --mcp-stdio --LogLevel Error, sendlogging/setLevel debug, verify logs flow at Debug.Out of scope
--mcp-stdio= None — all unchanged).