Guide · 6 min read

Troubleshooting

Common Code issues — diagnostics, logs, and where to get help.

Product stage: Pre-release development
Last reviewed: 2026-07-23
Successful result: The change is visible in the active project.

What this accomplishes

Common Code issues — diagnostics, logs, and where to get help.

When something breaks in Code — editor, language server, agent, sub-agents, search, git, or memory — start with diagnostics and the support channels below.

Current availability

This page documents behaviour verified in Miton development builds. Miton is still pre-release and is not publicly downloadable; invited beta users will receive a signed desktop build with automatic updates.

Before you start

A Miton development build and an active project containing source code.
A connected model. Trust the project before allowing file, terminal or Git actions.

Start with the evidence Miton already exposes

Open Settings → Privacy & Diagnostics, then record the application version, operating system, active project, selected model and exact failing action. For Code failures, also record the current branch, dirty files and language-server state. Do not copy provider keys, access tokens or document contents into a bug report.

Common issues

The agent is not finding the code I expect

The agent is using the code search. The code search is indexed per project. The user can:

Check the code search index status in the diagnostic surface. The status should be “indexed”. If the status is “indexing”, wait for the indexing to complete.
Check the .miton/argus-ignore file. The file may be excluding the file the user expects.
Manually trigger a re-index from the diagnostic surface.

The language server is not responding

The language server is started by the editor when the editor detects a file with a known language. The user can:

Check the language server status in the diagnostic surface. The status should be “running” for the current file’s language. If the status is “not found”, the language server is not on PATH; the user can install the language server or configure the language-server binary path in the settings surface.
Restart the language server from the diagnostic surface.

The sub-agent is stuck

The sub-agent is running in an isolated worktree. The sub-agent can be stuck on a task that is taking too long, or on a permission gate that the user has not answered. The user can:

Check the sub-agent dashboard under transparency and approvals. The dashboard shows the sub-agent’s status, the sub-agent’s tool calls, and the sub-agent’s cost.
Pause the sub-agent from the dashboard. The sub-agent pauses; the user can inspect the sub-agent’s state; the user can resume the sub-agent or cancel the sub-agent.
Cancel the sub-agent from the dashboard. The sub-agent’s work is discarded; the sub-agent’s branch is deleted; the worktree is removed.

The memory is making bad suggestions

The memory is a learning signal, not a black box. The user can:

Open the memory surface in the settings panel. The surface shows the rules, the patterns, and the confidence scores.
Identify the rule or pattern that is causing the bad suggestion. The rule is marked as the rule that was applied in the chat metadata.
Edit the rule, mark the pattern as ignored, or reset the memory.

The drift detection is flagging false positives

The drift detection is configured by thresholds. The user can:

Open the project intelligence settings under “Project intelligence → Drift thresholds”. The thresholds are configurable.
Increase the threshold for the drift category that is flagging false positives. The drift detection will be less sensitive to that category.

The convention memory is suggesting code the user does not want

The convention memory is a learning signal. The user can:

Open the memory surface in the settings panel. The surface shows the rules, the patterns, and the confidence scores.
Identify the rule that is causing the bad suggestion. The rule is marked as the rule that was applied in the chat metadata.
Edit the rule, mark the pattern as ignored, or reset the memory.

The file watcher is not picking up changes

The file watcher is configured by a debounce window and by ignore patterns. The user can:

Check the file-watcher status in the diagnostic surface. The status should be “watching”. If the status is “stopped”, the file watcher has stopped; the user can restart the file watcher from the diagnostic surface.
Check the ignore patterns in Settings under “Editor → File watcher → Ignore patterns”. The ignore patterns may be excluding the file the user expects.

The support channels

The support channels are in the settings panel under “Support”. The channels are:

The community forum — the user can post a question or a bug report to the community forum. The forum is monitored by the Miton team; the user can expect a response within 1-2 business days.
The bug tracker — the user can file a bug report on the bug tracker. The bug tracker is monitored by the Miton team; the user can expect a response within 1-2 business days.
The diagnostic log export — the user can export the diagnostic log and attach the log to a forum post or a bug report. The log is a JSON file; the log is safe to share (the log does not contain conversation content or file contents).
The in-app feedback — the user can send feedback from the settings panel under “Support → Feedback”. The feedback is attached to the next crash report (if the user has crash reports enabled).

The bug-report flow

The bug-report flow is:

The user reproduces the bug.
The user opens the diagnostic surface; the user exports the diagnostic log.
The user opens the bug tracker; the user creates a new bug report.
The user fills in the bug report:
- Title — a short, descriptive title.
- Description — a description of the bug, including the steps to reproduce.
- Expected behaviour — what the user expected to happen.
- Actual behaviour — what actually happened.
- Diagnostic log — the exported diagnostic log, attached.
The user submits the bug report.
The Miton team triages the bug report; the user is notified of the triage result.

The bug-report flow is the right shape for reporting a bug. The flow ensures the Miton team has the information they need to reproduce and fix the bug.

What success looks like

The diagnostic surface is the entry point for debugging. The surface shows the current state of every subsystem; the user can click a status to drill into the details.

The diagnostic log is the source of truth for debugging. The log is in NDJSON on disk; the log is rotated daily; the log is preserved for 7 days.

The support channels are the community forum, the bug tracker, and the in-app feedback. The user can export the diagnostic log and attach the log to a forum post or a bug report.