Skip to content

Override the default log file path by environment variable MAGIC_CONTEXT_LOG_PATH#183

Open
kecsap wants to merge 1 commit into
cortexkit:masterfrom
kecsap:master
Open

Override the default log file path by environment variable MAGIC_CONTEXT_LOG_PATH#183
kecsap wants to merge 1 commit into
cortexkit:masterfrom
kecsap:master

Conversation

@kecsap

@kecsap kecsap commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

View with Codesmith Autofix with Codesmith
Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.


Summary by cubic

Allow overriding the Magic Context log file path via MAGIC_CONTEXT_LOG_PATH. Both the plugin and dashboard honor the env var; blank values are ignored. If unset, logs fall back to ${TMPDIR}/<harness>/magic-context/magic-context.log (e.g., opencode or pi).

  • New Features
    • packages/plugin: getMagicContextLogPath reads MAGIC_CONTEXT_LOG_PATH (trimmed), with fallback to the harness temp dir.
    • packages/dashboard: resolve_log_path_for in Rust honors MAGIC_CONTEXT_LOG_PATH (trimmed), with tests for override, blank values, and fallback.
    • Docs updated across README.md, dashboard README, and dashboard reference to document the env var and fallback path.

Written for commit 47a8ef8. Summary will update on new commits.

Review in cubic

Greptile Summary

This PR adds a MAGIC_CONTEXT_LOG_PATH environment variable that overrides the default per-harness log file path in both the TypeScript plugin and the Rust dashboard. When the variable is unset or blank, behaviour is unchanged — the log resolves to ${TMPDIR}/<harness>/magic-context/magic-context.log.

  • TypeScript (data-path.ts): getMagicContextLogPath trims and checks the env var before falling back to the harness-based path; tests and env-state teardown are handled correctly.
  • Rust (log_parser.rs): resolve_log_path_for mirrors the TypeScript logic; three new tests cover override, fallback, and blank-value cases, but all three mutate global env state (std::env::set_var/remove_var) without synchronisation, making them racy under Cargo's default parallel test runner.
  • Docs/READMEs: All three documentation locations are updated to mention the env var and its fallback paths.

Confidence Score: 4/5

Safe to merge for production use; the Rust tests are racy and may produce intermittent CI failures.

The production path change is small and correct in both TypeScript and Rust. The only real concern is in the new Rust tests: all three tests modify MAGIC_CONTEXT_LOG_PATH via std::env::set_var/remove_var without any mutex or serial guard, and Cargo runs tests in parallel threads by default. This means the test that expects the env var to be absent can observe it being set by a concurrent test, causing intermittent failures on multi-core machines.

packages/dashboard/src-tauri/src/log_parser.rs — the new test block needs thread-safe env-var handling before it is reliable in CI.

Important Files Changed

Filename Overview
packages/dashboard/src-tauri/src/log_parser.rs Adds MAGIC_CONTEXT_LOG_PATH override to resolve_log_path_for; new tests are racy due to unsynchronised std::env::set_var/remove_var across parallel test threads.
packages/plugin/src/shared/data-path.ts Adds env-var override to getMagicContextLogPath — trim + truthiness guard is correct; logic is straightforward.
packages/plugin/src/shared/data-path.test.ts Adds three tests for env override/fallback/blank-value; env state saved and restored correctly in afterEach.
README.md Documentation updated to reflect MAGIC_CONTEXT_LOG_PATH override with correct fallback paths.
packages/dashboard/README.md Updated log path entry to document env var override and fallback.
packages/docs/src/content/docs/reference/dashboard.md Updated Logs section to document the env var; wording is functional though slightly dense.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Log path requested] --> B{MAGIC_CONTEXT_LOG_PATH set and non-blank?}
    B -- Yes --> C[Return env var value]
    B -- No --> D{Which harness?}
    D -- opencode --> E["${TMPDIR}/opencode/magic-context/magic-context.log"]
    D -- pi --> F["${TMPDIR}/pi/magic-context/magic-context.log"]
Loading
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[Log path requested] --> B{MAGIC_CONTEXT_LOG_PATH set and non-blank?}
    B -- Yes --> C[Return env var value]
    B -- No --> D{Which harness?}
    D -- opencode --> E["${TMPDIR}/opencode/magic-context/magic-context.log"]
    D -- pi --> F["${TMPDIR}/pi/magic-context/magic-context.log"]
Loading

Comments Outside Diff (1)

  1. packages/plugin/src/shared/data-path.ts, line 39-46 (link)

    P2 The JSDoc still says "Pi and OpenCode write to SEPARATE logs under their respective harness subtrees" — but that guarantee is now broken when MAGIC_CONTEXT_LOG_PATH is set. Both harnesses will resolve to the same file, interleaving their session traces. The comment should be updated to reflect the override, and users should be warned about this behaviour.

Reviews (2): Last reviewed commit: "Override the default log file path by en..." | Re-trigger Greptile

Greptile also left 1 inline comment on this PR.

Comment thread packages/docs/src/content/docs/reference/dashboard.md Outdated

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 5 files

Re-trigger cubic

@alfonso-magic-context alfonso-magic-context left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this, the MAGIC_CONTEXT_LOG_PATH override is a good idea and the plugin-side change is clean (single choke point in getMagicContextLogPath, trims and ignores blank, with tests). A couple of changes needed before merge:

  1. Please rebase onto master. The branch currently conflicts. We landed the config-location cutover (config + artifacts moved to the shared CortexKit location) since this PR was opened, which touches nearby docs/paths.

  2. The dashboard doc change overstates support. The PR updates packages/dashboard/README.md and the docs dashboard.md to say the dashboard Logs tab honors MAGIC_CONTEXT_LOG_PATH, but the dashboard's Rust log resolver (packages/dashboard/src-tauri/src/log_parser.rs, resolve_log_path_for) reads std::env::temp_dir() and does not read that env var. As written, a user who sets MAGIC_CONTEXT_LOG_PATH would have the plugin write to the custom path while the dashboard keeps reading the default tmp path, so the docs would be wrong.

    Two ways to resolve, either is fine:

    • Simplest: drop the dashboard doc edits from this PR and keep it plugin-only (the env override still works for the plugin's own log file).
    • Complete: also make resolve_log_path_for honor MAGIC_CONTEXT_LOG_PATH (read the env var first, fall back to the tmp path) so the dashboard Logs tab reads the same file the plugin writes. If you'd rather not touch Rust, say so and I'll add that part.

Everything else looks good. Once it's rebased and the dashboard claim is either dropped or backed by the Rust read, I'll merge.

Comment on lines +447 to +506

#[cfg(test)]
mod tests {
use super::{resolve_log_path_for, Harness};
use std::path::PathBuf;

#[test]
fn resolve_log_path_for_uses_harness_fallback_when_env_unset() {
std::env::remove_var("MAGIC_CONTEXT_LOG_PATH");

assert_eq!(
resolve_log_path_for(Harness::Opencode),
std::env::temp_dir()
.join("opencode")
.join("magic-context")
.join("magic-context.log")
);
assert_eq!(
resolve_log_path_for(Harness::Pi),
std::env::temp_dir()
.join("pi")
.join("magic-context")
.join("magic-context.log")
);
}

#[test]
fn resolve_log_path_for_honors_magic_context_log_path_override() {
let custom = std::env::temp_dir()
.join("custom")
.join("magic-context.log");
std::env::set_var(
"MAGIC_CONTEXT_LOG_PATH",
custom.to_string_lossy().to_string(),
);

assert_eq!(
resolve_log_path_for(Harness::Opencode),
PathBuf::from(&custom)
);
assert_eq!(resolve_log_path_for(Harness::Pi), PathBuf::from(&custom));

std::env::remove_var("MAGIC_CONTEXT_LOG_PATH");
}

#[test]
fn resolve_log_path_for_ignores_blank_magic_context_log_path() {
std::env::set_var("MAGIC_CONTEXT_LOG_PATH", " ");

assert_eq!(
resolve_log_path_for(Harness::Pi),
std::env::temp_dir()
.join("pi")
.join("magic-context")
.join("magic-context.log")
);

std::env::remove_var("MAGIC_CONTEXT_LOG_PATH");
}
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Env-var mutations in parallel tests are racy

All three new tests manipulate MAGIC_CONTEXT_LOG_PATH via std::env::set_var/remove_var, which is global, unsynchronised process state. Cargo runs tests in parallel threads by default, so resolve_log_path_for_uses_harness_fallback_when_env_unset can read the env var mid-assignment from either of the other two tests, producing intermittent failures.

The standard fix is either to gate each test with a Mutex around the env-mutation window, add the serial_test crate and annotate each test with #[serial], or run with RUST_TEST_THREADS=1 in CI. Without serialization, these tests will produce flaky results on any machine with more than one CPU core.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants