The detected filetype is PLAIN_TEXT, but the provided filetype was HTML

[u35tpus]

Describe the bug

goose generate the error below when generating Web UI:

Ran into this error: Server error: Failed to call Bedrock: ValidationException(ValidationException { message: Some("The detected filetype is PLAIN_TEXT, but the provided filetype was HTML."), meta: ErrorMetadata { code: Some("ValidationException"), message: Some("The detected filetype is PLAIN_TEXT, but the provided filetype was HTML."), extras: Some({"aws_request_id": "0b5ef2af-7f0f-4596-ba49-f4ed130e78b3"}) } }).

💡 Before filing, please check common issues:
https://block.github.io/goose/docs/troubleshooting

📦 To help us debug faster, attach your diagnostics zip if possible.
👉 How to capture it: https://block.github.io/goose/docs/troubleshooting/diagnostics-and-reporting/

A clear and concise description of what the bug is.

---

To Reproduce
Steps to reproduce the behavior:
Its difficult to say how to reproduce it. I can only say this thing happens when generating HTML code for sure. It can not be overcome other than by using another ai agent.

---

Expected behavior
A clear and concise description of what you expected to happen.

I would expect goose does not generate this error.

---

Screenshots
If applicable, add screenshots to help explain your problem.

---

Please provide the following information

• OS & Arch: [e.g. Ubuntu 22.04 x86]

• Interface: [UI / CLI]
  Goose CLI

• Version: [e.g. v1.0.2]
  1.21.0

• Extensions enabled: [e.g. Computer Controller, Figma]

developer, skills, todo, extensionmanager, filesystem

• Provider & Model: [e.g. Google – gemini-1.5-pro]
  Bedrock

arn:aws:bedrock:us-east-1:889799412502:inference-profile/us.anthropic.claude-opus-4-5-20251101-v1:0

---

Additional context
Add any other context about the problem here.

[u35tpus]

OS: Macos Tahoe 26.2

[u35tpus]

I asked goose analyze the problem and suggest the fix. Here is his response:

Bedrock ValidationException when viewing .html files: "The detected filetype is PLAIN_TEXT, but the provided filetype was HTML"

Summary

When using Goose with AWS Bedrock provider, viewing .html files (especially templates like Jinja/Django) causes a ValidationException error because Bedrock validates the content against the declared format and rejects files that don't look like valid HTML.

Error Message

Server error: Failed to call Bedrock: ValidationException(ValidationException { 
    message: Some("The detected filetype is PLAIN_TEXT, but the provided filetype was HTML."), 
    meta: ErrorMetadata { 
        code: Some("ValidationException"), 
        message: Some("The detected filetype is PLAIN_TEXT, but the provided filetype was HTML."), 
        extras: Some({"aws_request_id": "88644593-d751-401a-8a13-d058b4db339c"}) 
    } 
})

Environment

• Provider: AWS Bedrock (aws_bedrock)
• Model: us.anthropic.claude-opus-4-5-20251101-v1:0 (but affects all Bedrock models)
• OS: macOS (but likely affects all platforms)

Steps to Reproduce

1. Configure Goose to use AWS Bedrock provider
2. Open a project containing .html template files (e.g., Jinja2, Django templates)
3. Use the text editor tool to view an HTML template file:

   View the file app/templates/my_template.html
   

4. The error occurs when Goose sends the file content to Bedrock

Example file that triggers the error (Jinja2 template):

{% extends "base.html" %}
{% block content %}
<div class="container">
    {{ some_variable }}
</div>
{% endblock %}

Root Cause Analysis

1. Text Editor Creates Embedded Resource

When viewing a file, text_editor_view() in crates/goose-mcp/src/developer/text_editor.rs creates an embedded resource:

// Line 697
Ok(vec![
    Content::embedded_text(uri, content).with_audience(vec![Role::Assistant]),
    // ...
])

2. Embedded Text Uses File URI

The embedded_text() function in the rmcp crate creates a ResourceContents::TextResourceContents with the file URI:

// rmcp/src/model/content.rs:110
pub fn embedded_text<S: Into<String>, T: Into<String>>(uri: S, content: T) -> Self {
    RawContent::Resource(RawEmbeddedResource {
        meta: None,
        resource: ResourceContents::TextResourceContents {
            uri: uri.into(),
            mime_type: Some("text".to_string()),  // Generic mime type
            text: content.into(),
            meta: None,
        },
    })
}

3. Bedrock Format Detection Uses File Extension

The to_bedrock_document() function in crates/goose/src/providers/formats/bedrock.rs determines the Bedrock document format based on the file extension, ignoring the mime_type:

// Lines 229-251
fn to_bedrock_document(
    tool_use_id: &str,
    content: &ResourceContents,
) -> Result<Option<bedrock::DocumentBlock>> {
    let (uri, text) = match content {
        ResourceContents::TextResourceContents { uri, text, .. } => (uri, text),
        // ...
    };

    let filename = Path::new(uri)
        .file_name()
        .and_then(|n| n.to_str())
        .unwrap_or(uri);

    // Return None if the file type is not supported
    let (name, format) = match filename.split_once('.') {
        Some((name, "txt")) => (name, bedrock::DocumentFormat::Txt),
        Some((name, "csv")) => (name, bedrock::DocumentFormat::Csv),
        Some((name, "md")) => (name, bedrock::DocumentFormat::Md),
        Some((name, "html")) => (name, bedrock::DocumentFormat::Html),  // <-- PROBLEM
        _ => return Ok(None), // Falls back to text
    };

    // Creates DocumentBlock with the format
    Ok(Some(
        bedrock::DocumentBlock::builder()
            .format(format)
            .name(name)
            .source(bedrock::DocumentSource::Bytes(text.as_bytes().into()))
            .build()
            // ...
    ))
}

4. Bedrock Validates Content Against Format

When Bedrock receives a document with format: Html, it validates the content to ensure it's actually valid HTML. Template files (Jinja2, Django, etc.) contain template syntax that isn't valid HTML, so Bedrock rejects them with:

"The detected filetype is PLAIN_TEXT, but the provided filetype was HTML."

The Bug

The code uses file extension to determine Bedrock document format, but the content may not match the expected format:

• .html files containing templates (Jinja2, Django, etc.) are not valid HTML
• .html files containing HTML fragments may not pass validation
• Extension-based format detection is unreliable for content validation

When to_bedrock_document() returns None, the content is sent as plain text (via ToolResultContentBlock::Text), which always works.

Proposed Solutions

Option 1: Remove HTML from Supported Formats (Quick Fix)

Simply don't use Bedrock document blocks for HTML files - let them fall back to plain text:

let (name, format) = match filename.split_once('.') {
    Some((name, "txt")) => (name, bedrock::DocumentFormat::Txt),
    Some((name, "csv")) => (name, bedrock::DocumentFormat::Csv),
    Some((name, "md")) => (name, bedrock::DocumentFormat::Md),
    // HTML removed - falls back to plain text
    _ => return Ok(None),
};

Pros: Simple, safe, immediate fix
Cons: Loses potential benefits of Bedrock's HTML document handling

Option 2: Content Sniffing (Better)

Validate content before declaring HTML format:

Some((name, "html")) => {
    // Only use HTML format if content looks like valid HTML
    let trimmed = text.trim();
    if trimmed.starts_with("<!DOCTYPE") || 
       trimmed.starts_with("<!doctype") ||
       trimmed.starts_with("<html") ||
       trimmed.starts_with("<HTML") {
        (name, bedrock::DocumentFormat::Html)
    } else {
        return Ok(None); // Fall back to text
    }
}

Pros: Preserves HTML handling for valid HTML files
Cons: More complex, may miss edge cases

Option 3: Use mime_type from ResourceContents (Best Long-term)

Respect the mime_type field in ResourceContents when available, only fall back to extension-based detection when needed:

fn to_bedrock_document(
    tool_use_id: &str,
    content: &ResourceContents,
) -> Result<Option<bedrock::DocumentBlock>> {
    let (uri, text, mime_type) = match content {
        ResourceContents::TextResourceContents { uri, text, mime_type, .. } => 
            (uri, text, mime_type),
        // ...
    };

    // Prefer mime_type over extension
    let format = match mime_type.as_deref() {
        Some("text/plain") | Some("text") => Some(bedrock::DocumentFormat::Txt),
        Some("text/csv") => Some(bedrock::DocumentFormat::Csv),
        Some("text/markdown") => Some(bedrock::DocumentFormat::Md),
        Some("text/html") => {
            // Validate content before declaring HTML
            // ...
        }
        _ => {
            // Fall back to extension-based detection
            // ...
        }
    };
    // ...
}

Pros: More correct, respects semantic information
Cons: Requires coordination with how mime_type is set upstream

Recommendation

I recommend Option 1 as an immediate fix since:

1. It's safe and simple
2. HTML files are common in codebases (templates, components)
3. Plain text fallback works perfectly fine for LLM context
4. Bedrock's HTML validation is too strict for real-world development files

Option 2 or 3 could be considered for a more complete solution in the future.

Related Code Paths

• crates/goose-mcp/src/developer/text_editor.rs - text_editor_view() function (line 697)
• crates/goose/src/providers/formats/bedrock.rs - to_bedrock_document() function (lines 229-251)
• crates/goose/src/providers/formats/bedrock.rs - to_bedrock_tool_result_content_block() function (uses document blocks)

[u35tpus]

Prompt i used to generate goose bug report above:

`I came across error when running goose:

Ran into this error: Server error: Failed to call Bedrock: ValidationException(ValidationException { message: Some("The detected filetype is PLAIN_TEXT, but the provided filetype was HTML."), meta: ErrorMetadata { code: Some("ValidationException"), message: Some("The detected filetype is PLAIN_TEXT, but the provided filetype was HTML."), extras: Some({"aws_request_id": "xxx-xx-xxx-xxx-xxx"}) } }).

Please retry if you think this is a transient or recoverable error.

analyze sessions.db and wal here (you can dump it using scripts/dump-goose-sessions.py) ~/.local/share/goose/sessions/ and goose sources at /Users/myusernamehere/work/goose and find out why the error occurs and how to fix it

i want to submit your finding to goose issues on github. Prepare full description of a problem, add evidences. Remove my personal data from it, i mean remove at least my name and last name, any transaction ids, etc.
`

[blackgirlbytes]

/goose please solve this issue