Report a problem

A useful report lets the Tejus team reproduce the problem, identify the failing layer, and compare expected behavior with the exact observed result. Preserve the work first, then reduce the failure before collecting more data.

Ways to reach the Tejus team

What the feedback dialog sends

The Share feedback dialog asks for an optional category (Bug, Session, UI, Performance, Idea, or Other) and your details (required, up to 5,000 characters). Tejus adds diagnostics about the moment you submit:

• App version, platform, window size, language, and user agent
• The open chat's provider and model, project kind, environment, runtime and interaction modes, session status, and latest turn state
• The number of messages and activities in the chat, and whether an approval, a question, or an error was pending
• The submission time

It never includes prompts, messages, file paths, or logs, and it is not linked to your Tejus account. The dialog sends text only, so if you want a reply or need to share screenshots or log excerpts, e-mail support@tejusai.com and mention that you also sent feedback.

What a crash report sends

A crash report is sent only when you click the send button. It contains the error message, the stack trace, where in the app it happened, the Tejus version, the OS and CPU architecture, and a random installation ID; when you are signed in, it is sent with your Tejus account sign-in. File paths and e-mail addresses are removed and long text is shortened before sending, and a scrubbed copy is kept in %USERPROFILE%\.tejus\userdata\logs\tejus-crash-reports.log. A delivered report shows a reference ID; quote it if you follow up by e-mail.

Before you report

1. Check the relevant troubleshooting and workflow guide.
2. Note your Tejus version from Settings → System tools → Version.
3. Reproduce the problem once with the smallest safe setup.
4. Preserve the failing state and exact evidence.
5. Remove secrets and private data from everything you plan to share.

Send one report per root failure. When you have new evidence for a problem you already reported, add it to the same e-mail thread instead of starting another.

Define the failure boundary

State which layer fails:

• Desktop launch or update
• Tejus account, Tejus Cloud, or your own API keys
• Provider detection or authentication
• Model discovery
• Task lifecycle or provider runtime
• Git or managed worktree
• Browser runtime
• Pull-request workflow
• Automation
• Agent Gateway
• External MCP
• Website or documentation

When unsure, describe the boundary rather than guessing a cause.

Build a minimal reproduction

A strong reproduction includes:

1. Clean starting state
2. Exact action
3. Exact result
4. Expected result
5. Whether the failure is consistent
6. Smallest environment that still fails

Example:

Starting state:
- Tejus 1.0.1 on Windows 11
- Codex CLI x.y.z, authenticated
- Clean test repository on a local branch
- One task using approval-required mode

Steps:
1. Create a task in a managed worktree.
2. Select the documented model and default options.
3. Send: "Read README.md and summarize it. Do not modify files."
4. Wait for the first provider response.

Actual:
- Task changes to error after 8 seconds.
- Exact message: <redacted error>
- No files changed.

Expected:
- A read-only summary and an idle task.

Frequency:
- 3/3 attempts in this repository.
- 0/2 attempts in an empty repository.

Avoid reproductions that begin with "after hours of work" unless the duration itself is essential.

Environment information

Include:

• Windows version
• Tejus version
• Provider name
• For a coding-agent CLI: executable path and version, and the authentication method without the credential
• For the Tejus agent: whether you use Tejus Cloud or your own API key, and which model
• Model and provider-specific options
• Local checkout or worktree
• Runtime permission mode
• Repository type and size when relevant
• Whether the failure occurs in a disposable repository

Use placeholders for private paths and names.

Exact task evidence

For task failures, include:

• Task status
• Turn state
• Exact error text
• Time range with timezone
• Last successful activity
• Whether approval or user input was pending
• Whether interruption occurred
• Whether the provider process continued
• Whether files or remote state may have changed

Do not paste a complete private transcript.

Git evidence

For Git or worktree problems, include redacted output from:

git status --short --branch
git rev-parse HEAD
git worktree list --porcelain
git diff --check
git diff --stat

Do not share a proprietary diff merely because git diff --stat was insufficient. Describe the affected paths or create a public minimal repository.

Provider evidence

For a coding-agent CLI, run in PowerShell:

Get-Command <provider-command>
<provider-command> --version

State whether authentication and the same minimal request work directly in the provider CLI.

Never include API keys, tokens, cookies, credential files, or complete provider configuration.

Browser evidence

Include:

• Browser tool name
• Task and tab scope
• URL generalized when private
• Exact error code
• Whether the action may have committed
• Fresh snapshot result after the failure
• Relevant redacted console or network metadata
• Screenshot only when pixels matter

Do not include credentials, private page content, or authenticated screenshots.

Automation and integration evidence

For automations:

• Schedule
• Current or paused state
• Last run time and outcome
• Stop condition
• Project, provider, model, and environment
• Whether another run overlapped
• Whether any external effect duplicated

For the Agent Gateway:

• Caller context and capability result
• Tool name
• Target project, environment, and runtime mode
• Exact rejection or result

For External MCP:

• Pairing, paired, or connected state
• Integration scopes and project allowlist without credentials
• Client type
• Whether tejus_overview succeeds
• Exact lifecycle, rate, or active-task error
• Whether the integration is expired or revoked

Never share the raw integration credential or private credential file.

Logs and diagnostic evidence

Share a short, redacted excerpt from the relevant log file around the time of the failure rather than the whole file. For a stuck or inconsistent task, an agent can run tejus_diagnose_thread; share a redacted summary of its result.

Read Diagnostics for log locations and before claiming an event was absent.

Secret and privacy review

Remove:

• API keys, tokens, cookies, passwords, and authorization headers
• Private prompts and model output
• Proprietary source code
• Customer or personal data
• Private repository names and URLs
• Local usernames, hostnames, and home paths
• Internal services and URLs
• Account, organization, integration, project, and task IDs when unnecessary
• Screenshots containing private browser or terminal content

Report template

Paste this into the feedback dialog or an e-mail to support@tejusai.com:

## Summary

A one-sentence description of the observable failure.

## Environment

- Windows version:
- Tejus version:
- Provider (and CLI version, or Tejus Cloud / own API key):
- Model/options:
- Environment: local checkout | worktree
- Runtime mode:

## Starting state

What was true before the reproduction?

## Steps to reproduce

1.
2.
3.

## Expected behavior

What should have happened?

## Actual behavior

What happened instead? Include the exact redacted error.

## Frequency

Always, intermittent, or one occurrence? Include attempt counts.

## Impact

What work is blocked, lost, duplicated, or unsafe?

## Evidence

- Time range and timezone:
- Git status/stat:
- Provider direct test:
- Redacted log excerpt:
- Crash report reference ID:

## Recovery attempts

List each change separately and its result.

What not to do

• Do not send "it does not work" without a reproduction
• Do not send the complete Tejus data folder or database
• Do not paste an entire private task transcript
• Do not run destructive cleanup merely to make the report simpler
• Do not claim a failure is provider-wide without testing the provider directly
• Do not claim an event was absent based on an incomplete diagnostic source
• Do not combine unrelated failures into one report

Reporting checklist

• The failing layer was identified or bounded honestly
• The smallest safe reproduction was written
• Exact environment and versions were included
• Expected and actual behavior were separated
• Frequency and impact were stated
• Evidence includes exact times
• Everything shared was manually redacted
• Exposed credentials were rotated or revoked
• The report is focused enough to verify a fix