[Bug]: Malformed local SKILL.md causes unreadable thread failure and poor diagnostics

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

Steps to reproduce

1. Start T3 Code from WSL2 Ubuntu on Windows 11 with npx t3 .
2. Open a project that contains local Codex skills under .agent/skills/.../SKILL.md
3. Have at least one malformed skill file with invalid YAML frontmatter
4. Create a new thread
5. Send a prompt

Concrete example from my project:

A local skill file like:

---
name: monorepo-scaffolding
description: Establish DevSuite’s monorepo “soil”: pnpm workspaces, TypeScript project references, ...
---

fails YAML parsing because the description value is unquoted and contains :.

Example failing path:

/home/sebherrerabe/repos/devsuite/.agent/skills/monorepo-scaffolding/SKILL.md

Expected behavior

• T3 Code should surface the provider/runtime error clearly and persistently at least for some reasonable time
• The full error message should be readable in the thread UI without needing to react quickly to a transient banner
• The full error should be easy to copy from the UI
• The thread/work log should retain enough detail to diagnose the problem later
• Ideally, malformed local skills should be skipped with a warning instead of making the thread fail

Actual behavior

• The thread enters an error state after sending the prompt
• The visible error in the UI is hard to read and easy to miss
• The banner appears truncated/clamped
• The work log mostly shows generic Runtime error entries instead of preserving the full useful diagnostic
• I had to take a fast screenshot to read the real cause

The actual underlying error was:

ERROR codex_core::codex: failed to load skill /home/sebherrerabe/repos/devsuite/.agent/skills/monorepo-scaffolding/SKILL.md: invalid YAML: mapping values are not allowed in this context at line 2 column 50

Impact

Major degradation or frequent failure

Version or commit

main

Environment

Windows 11 WSL2 Ubuntu Running T3 Code via npx t3 . Browser UI on localhost:3773 Codex provider Model: gpt-5.4

Logs, stack traces, or screenshots

2026-03-14T16:11:12.550224Z ERROR codex_core::codex: failed to load skill /home/sebherrerabe/repos/devsuite/.agent/skills/monorepo-scaffolding/SKILL.md: invalid YAML: mapping values are not allowed in this context at line 2 column 50

Relevant app behavior from logs:


[17:11:12.529] INFO: codex app-server opening thread {
  threadId: 'c97edc6d-385b-4b65-b20c-7582f4c5aaf8',
  requestedRuntimeMode: 'full-access',
  requestedModel: 'gpt-5.4',
  requestedCwd: '/home/sebherrerabe/repos/devsuite',
  resumeThreadId: null
}
[17:11:12.576] INFO: codex app-server thread open resolved {
  threadId: 'c97edc6d-385b-4b65-b20c-7582f4c5aaf8',
  threadOpenMethod: 'thread/start',
  requestedResumeThreadId: null,
  resolvedThreadId: '019ced1d-b32a-7870-82e8-7056c37064b0',
  requestedRuntimeMode: 'full-access'
}
This suggests thread/start itself succeeds, and the failure happens afterward when local skills are loaded.

Workaround

Fix or remove malformed local skill files in the project.

In my case, quoting the YAML description values resolves the issue, for example:

description: "Establish DevSuite’s monorepo “soil”: pnpm workspaces, TypeScript project references, lint/format/husky tooling..."
Notes
This is not just a project-local content error. The project error is valid, but T3 Code currently makes it too difficult to understand what broke since the error gets displayed and dissapears in 1 second.

Start in apps/web by tracing the thread prompt flow after thread/start succeeds, focusing on how provider/runtime errors reach the banner and work log. Use the malformed local .agent/skills/.../SKILL.md example and the logged YAML error as the reproduction case. Done means the full diagnostic remains readable, copyable, and retained in the thread or work log.