Debug mode

Debug mode gives the selected provider a shared, evidence-first debugging policy. It is designed for a reported defect whose cause is not yet established—not for general feature implementation or an unverified request to "fix whatever looks wrong." It works the same way for every provider, including the built-in Tejus agent.

Debug or Plan

Use Debug when the primary problem is diagnosis: observe a symptom, reproduce it, narrow competing hypotheses, repair the smallest root cause, and prove the symptom is gone.

Use Plan when the behavior is understood but the implementation or product decision still needs design. Debug mode does not make the provider plan-only, and Plan mode does not replace reproduction evidence.

Start Debug mode

Open the composer’s + menu and choose Debug mode, or run:

/debug

A Debug badge appears in the composer footer while the mode is active. Send the defect report as a normal message with the observed behavior, reproduction boundary, relevant environment, and what would count as verified resolution.

Return to normal mode by clicking the Debug badge, choosing Debug mode again in the + menu, or running:

/default

Evidence loop

Debug mode instructs the provider to follow this order:

1. Observe the real current state before editing.
2. Reproduce the symptom locally when possible.
3. Investigate logs, errors, stack traces, and testable hypotheses.
4. Fix the smallest root cause instead of masking the symptom.
5. Verify the original reproduction and the relevant regression checks.

A passing test that never exercised the reported symptom is not enough. A changed code path without a repeated observation is not verification.

Reproduction questions

Some failures require state only you can create—for example a specific browser account, an action in another app, or an intermittent UI sequence. When the provider can pause for structured input, Debug mode asks one focused reproduction question with Reproduced, Could not reproduce, and Cancel choices. Otherwise the provider writes the steps as normal text, ends the turn, and continues after your next message.

Keep the requested application or state open until the provider says the evidence has been captured. Tejus cannot observe an external action unless the relevant browser, terminal, logs, or other signal is actually available to the thread. For web apps, the in-app browser lets the agent see the same page you do.

Permissions and safety

Debug mode preserves the thread’s current runtime permission mode. It does not grant broader file, shell, browser, or network access.

Inspect before repeating a mutation. A timed-out click, command, or remote action may already have taken effect. Observe the new state before deciding whether a retry is safe.

Persistence and continuation

The interaction mode is stored on the thread. Debug stays on across queued messages and app restarts, and it carries over to forks and provider handoffs, until you explicitly return to normal mode or choose another mode.

If the thread also has a thread goal, Debug changes how each turn diagnoses the defect; it does not bypass goal pause rules, pending approvals, user-input gates, or interruption handling.

When diagnosis is blocked

A useful blocked report states:

• What was inspected
• Whether the symptom was reproduced
• Evidence supporting or rejecting each leading hypothesis
• What source or environment remains inaccessible
• The smallest next action that could resolve the uncertainty

Do not let the provider convert missing evidence into a confident root-cause claim.

Debug completion checklist

• Original symptom and environment recorded
• Reproduction attempted before editing
• Evidence distinguishes the root cause from nearby symptoms
• Fix is scoped to the established cause
• Regression coverage added or updated when practical
• Relevant focused and broader checks passed
• Original reproduction repeated after the fix
• Remaining uncertainty and inaccessible evidence reported
• Thread returned to normal mode when diagnosis is finished