xai-org/grok-build · error

The change was applied, but Doctor still reports `{}`.

Error message

The change was applied, but Doctor still reports `{}`.

What it means

After applying a doctor fix, the command re-collects the doctor report to verify the fix took effect. If a finding with the same id as the fix outcome is still present, it means the change was written but did not resolve the problem, so the command fails rather than reporting false success.

Source

Thrown at crates/codegen/xai-grok-pager/src/doctor_cmd/mod.rs:175

            writeln!(writer, "Fix cancelled.")?;
            return Ok(());
        }
    }

    let outcome = crate::diagnostics::apply_fix(plan)?;
    if outcome.activation() == FixActivation::SatisfiedNow {
        // Use the shell stored on the outcome (from planning), not `$SHELL`.
        // `$SHELL` may be missing or no longer match the shell the plan targeted.
        let post_report = crate::diagnostics::configured_report(
            collect_report_with(crate::diagnostics::probes::collect_standalone(terminal)),
            outcome.managed_alias_is_configured(),
        );
        if post_report
            .findings
            .iter()
            .any(|finding| finding.id == outcome.id())
        {
            anyhow::bail!(
                "The change was applied, but Doctor still reports `{}`.",
                outcome.id()
            );
        }
    } else if !crate::diagnostics::verify_persistent_fix(&outcome) {
        anyhow::bail!(
            "The change was applied, but Doctor could not verify `{}` in persistent configuration.",
            outcome.id()
        );
    }

    writeln!(
        writer,
        "\n{}",
        crate::diagnostics::format_fix_success(&outcome)
    )?;
    Ok(())
}

View on GitHub (pinned to bc7f02eddd)

Solutions

1. Identify the still-reported finding id from the message and check what re-introduces it (env vars, project config overriding the fixed file).
2. Apply the fix at the correct config layer (the one with highest precedence).
3. Manually edit the setting if the automated fix targets the wrong file/location.
4. Re-run `grok doctor` to see all remaining findings and address contributing causes together.

Example fix

// before: fix writes user config, but project config overrides
// after: remove the overriding key in the project config, or fix that layer directly
grok doctor fix-config --yes && grok doctor   # confirm finding is gone

// After fixing, re-collect the report yourself before declaring success
let post = doctor::collect_report();
if post.findings.iter().any(|f| f.id == fixed_outcome.id()) {
    eprintln!("Fix did not clear finding {} — check overriding config layers", fixed_outcome.id());
}

if let Err(e) = doctor_fix(args) {
    if e.to_string().starts_with("The change was applied, but Doctor still reports") {
        // fall back to manual remediation of the named finding id
        eprintln!("{e}\nFix the setting at the highest-precedence config layer.");
    } else { return Err(e); }
}

When it happens

Trigger: `apply_fix_plan` post-check: after the fix is applied, `post_report.findings` still contains a finding whose `id == outcome.id()` — the fix ran but the underlying condition persists (reached via `run_fix` and the associated tests).

Common situations: Another config layer (env var, project config) overrides the fixed value; the fix wrote to a file that is later shadowed; partial fix for a condition with multiple contributing causes; stale cached state re-creating the finding.

Related errors

• The change was applied, but Doctor could not verify `{}` in
• Session does not exist locally (session registry is disabled
• Doctor fixes require interactive input and output.
• Cannot apply this fix without confirmation. Run it in an int
• no target specified

AI-assisted analysis of xai-org/grok-build@bc7f02eddd (2026-08-31). Data as JSON: /api/errors/74503c1de3683c37. Report an issue: GitHub.