Recently, I created an intelligent task management and bug triage system powered by AI to help me daily. It integrates AI assistant, browser, and local source/documents.
A Day in Bug Triage: How It Works
Let me show you a typical bug triage session and how the AI infrastructure helps with real development work.
Starting the Day
In terminal: I start the day by asking for a triage report:
> start triage gtk
Running ./scripts/moz-gtk-triage.sh...
✓ Queried Bugzilla: 32 untriaged GTK bugs found
✓ Generated gtk-2-triage.html
Checking browser tabs...
✓ Found existing tab with gtk-2-triage.html
✓ Switched to the tab
✓ Reloaded to show updated list
✓ Ready! Click "Check" buttons to analyze bugs.
In browser: A list of 32 untriaged GTK bugs appears, each with a "Check" button.
Analyzing My First Bug
In browser: I click the "Check" button next to Bug 1993100.
In terminal: The command appears instantly:
> /check-bug 1993100
Loading Bug 1993100...
✓ Fetched from Bugzilla REST API
Bug 1993100: Crash in [@ guess_category_value] at startup in ESR 140.3
Status: NEW (untriaged, severity: --)
Component: Widget: Gtk
Assigned: nobody@mozilla.org
Summary:
The bug reports a crash during Firefox ESR 140.3 startup. The crash
occurs in guess_category_value, which is a glibc function for locale/
category initialization.
Stack trace shows:
guess_category_value (glibc locale handling)
→ setlocale (locale initialization)
→ gtk_init (GTK library initialization)
→ XRE_main (Firefox main entry point)
Potential Root Cause (from comments):
Comment #1 identifies this as "yet another getenv() crash likely due
to our calling setenv" - indicating this is a known class of crashes
related to setenv/getenv interactions during startup.
Recommended Actions:
1. Set severity to S3 (affects startup but specific to ESR + glibc 2.39)
2. Ask reporter for: locale settings, GTK version, distribution
3. Request STR (steps to reproduce) with LANG=C workaround test
4. Check if similar to Bug 1987556 (GTK component init timing)
Diving Deeper
In terminal: The AI's summary is helpful, but I want to understand the bug better. I see guess_category_value in the crash but don't know what it does:
> what is guess_category_value?
guess_category_value is a glibc internal function used during locale
and internationalization (i18n) initialization. It determines which
locale value to use by checking multiple sources in priority order.
The function is part of glibc's gettext implementation and checks:
1. LANGUAGE environment variable (colon-separated locale list)
2. LC_ALL, LC_xxx, or LANG environment variables
3. System-dependent defaults
A crash here typically means:
- Locale environment variables are inconsistent or corrupted
- Race condition during multi-threaded initialization
- NULL pointer from missing or malformed environment data
> please find the source of guess_category_value() from web
Searching for glibc source code...
Found in glibc source (intl/dcigettext.c):
https://codebrowser.dev/glibc/glibc/intl/dcigettext.c.html
✓ Opened in browser tab
The function is part of glibc's gettext (internationalization) code.
It accesses environment variables to determine locale settings during
initialization.
In browser: A new tab opens showing the glibc source code.
In terminal: I want to read the source code in my editor. Let me ask the assistant to clone the repository for me:
> clone the repository of glibc under ./sources/
Cloning glibc repository...
✓ git clone https://sourceware.org/git/glibc.git sources/glibc
✓ Cloned into sources/glibc
> open dcigettext.c in my editor
✓ Opening sources/glibc/intl/dcigettext.c in emacsclient
In editor: The file sources/glibc/intl/dcigettext.c opens.
Checking Knowledge Base
In terminal: I ask the assistant to search the knowledge base:
> check our knowledge base for locale initialization issues
Found 2 documents:
1. gtk-xkb-context-null-crash-bug-1987556.md
- XKB context initialization timing
- Similar null pointer patterns
2. firefox-snap-packaging.md
- Snap environment variable handling
- Locale setup in containerized environments
Reading gtk-xkb-context-null-crash-bug-1987556.md...
Key insight: "GTK initialization must happen after all
environment setup. Bug 1987556 showed that XKB context
creation fails when locale is not yet initialized."
Taking Action
In terminal: Now I understand the issue. Let me update the bug:
> add a comment explaining the issue and asking for more info
Checking for bug tab...
✓ Found Bug 1993100 tab in browser
Injecting comment script...
✓ Filled comment textarea with:
"This appears to be a locale initialization timing issue.
The crash in guess_category_value indicates GTK is trying
to initialize locale handling before the environment is
fully set up.
This is similar to Bug 1987556 where we found GTK component
initialization was happening too early.
Could you please provide:
1. Output of: `locale` command
2. Output of: `echo $LANG $LC_ALL $LC_CTYPE`
3. GTK version
4. Try this workaround: `LANG=C firefox-esr`"
✓ Ready for your review in browser tab
(Comment is filled but not submitted yet)
In browser: I review the comment to make sure it's correct.
In terminal: I submit it:
> looks good, submit it and set severity to s3
✓ Setting severity to S3...
✓ Clicking "Save Changes" button...
✓ Bug updated
Logging Your Work
In terminal: I log the work I've done on this bug:
> /work-log-bug this bug
Analyzing Bug 1993100...
✓ Fetched from REST API
✓ Reviewed comments (including the one we just added)
✓ Reviewing our conversation history
✓ Summarizing your actions and investigation...
Added to work.log:
- TRACK: Bug 1993100 - Crash in guess_category_value at startup
- analyzed crash signature (glibc locale/category initialization)
- researched guess_category_value function (glibc gettext)
- found and reviewed source code in intl/dcigettext.c
- cloned glibc repository for deeper investigation
- compared with Bug 1987556 (similar GTK init timing issue)
- searched knowledge base for locale initialization issues
- set severity to S3
- added comment requesting locale environment info
- suggested LANG=C workaround
A Complex Bug Needs Documentation
In browser: Later in the triage, I encounter Bug 1993502 about implementing window cloaking detection for Linux virtual desktops.
In terminal: This concept is unfamiliar, so I start asking questions:
> what is cloaking in Windows?
Window cloaking is a Windows API feature (DWM_CLOAKED attribute) that
hides windows without destroying them. The window exists and runs, but
doesn't appear on screen or in the window list.
Common uses:
- Virtual desktop switching (hide windows on inactive desktops)
- Tab management in browsers (hide background tabs)
- UWP app suspension
> do we have any solution like cloaking for Linux?
Yes, but it depends on whether you're using X11 or Wayland:
**X11: YES - We have a solution! ✅**
Uses Extended Window Manager Hints (EWMH) specification:
- `_NET_CURRENT_DESKTOP` - Which workspace is currently active
- `_NET_WM_DESKTOP` - Which workspace each window is on
- Perfect detection by comparing these two values
- 100% accurate, standardized across all X11 window managers
**Wayland: NO - No standard solution ❌**
Each compositor handles virtual desktops differently:
- GNOME/Mutter: No API to query workspace state
- KDE/KWin: Has protocols but not standardized
- Sway: Compositor-specific protocols only
- No Wayland protocol equivalent to Windows DWM_CLOAKED or X11 EWMH
The challenge: We can implement perfect workspace detection for X11,
but Wayland fundamentally doesn't provide the necessary APIs.
> what are related bugs about this?
Searching Bugzilla and knowledge base...
Found 3 related bugs:
- Bug 1993502: Investigate implementing isCloaked for Linux
- Bug 1515448: Wayland windows unresponsive on different workspaces
- Bug 1600261: Wayland windows unresponsive when hidden
These all relate to Firefox not knowing its workspace visibility on Linux,
causing unexpected workspace switching when opening links from external apps.
In terminal: I ask to summarize the conversation and create a document in the knowledge base.
> this is complex. Create a knowledge base document about
> Linux virtual desktop window cloaking
Creating new knowledge base document...
Synthesizing information from our conversation...
✓ Your questions about cloaking, X11, and Wayland
✓ My explanations of EWMH, frame callbacks, and protocols
✓ Bug comments from 1515448, 1993502, 1967234
✓ Codebase searches for Wayland visibility handling
✓ Wayland protocol documentation
✓ Comparison with Windows DWM_CLOAKED
Writing comprehensive document from all this context...
✓ Created: knowledge-base/linux-virtual-desktop-window-cloaking.md
- Organized all our discussion into clear sections
- Added technical details and code examples
- Included all related bugs and references
- Documented both X11 solution and Wayland limitations
✓ Generated keywords: .keywords.json created
In terminal: I ask to open the document in a browser:
> open this document in a browser tab
Converting markdown to HTML...
✓ Generated: kb-html/linux-virtual-desktop-window-cloaking.html
✓ Opened in browser tab
In browser: The knowledge base document appears, formatted and ready to read.
In terminal: I log this work:
> /work-log-bug 1993502
Added to work.log:
- TRACK: Bug 1993502 - Implement isCloaked for Linux virtual desktops
- researched Windows cloaking API (DWM_CLOAKED)
- investigated Linux/Wayland alternatives
- found related bugs: 1515448, 1600261
- created knowledge base document
Continuing Through the List
In browser: I continue clicking "Check" buttons for the remaining bugs. Some are straightforward (quick triage decisions), others require deeper investigation.
End of Day Summary
In terminal: At the end of the day, I ask for a summary:
> summary of today's triage work
Triage Summary for 2025-10-10:
==============================
Bugs Triaged: 8 bugs analyzed in detail
Quick triage (S3/S4, needinfo):
- Bug 1993100: locale init crash → S3, needinfo reporter
- Bug 1991369: viewport bounds → S3, assigned to :stransky
- Bug 1967452: Flatpak icon → S4, needinfo
Deep investigations:
- Bug 1515448: Virtual desktop cloaking
→ Created knowledge base document
Knowledge base additions:
- linux-virtual-desktop-window-cloaking.md
Work log updated: 6 entries added
The Magic Behind It: Three AI Components
What you just experienced is powered by three integrated AI infrastructure components working together:
1. foxmcp - Browser Automation
What it does: Gives Claude AI complete control over your Firefox browser.
Key capabilities: - Opens, closes, switches between tabs - Extracts text and HTML from pages - Fills forms, clicks buttons, navigates - Searches browser history - Runs predefined automation scripts (scripts for Bugzilla, Google Calendar, ...)
How it works: Model Context Protocol (MCP) server connects Claude to Firefox via WebExtension API.
In the story: foxmcp opened tabs, extracted bug comments, submitted bug updates, and reloaded the triage report.
2. kb-indexer - Semantic Knowledge Search
What it does: Maintains an searchable index of your investigation documents.
Key capabilities: - AI-powered keyword generation from documents - Semantic similarity search (finds related concepts) - Fast SQLite-based keyword search - Builds relationships between keywords over time
How it works: Claude Code analyzes documents to extract keywords, stores them in SQLite, and uses AI to discover relationships between terms.
In the story: kb-indexer found the related Bug 1987556 investigation and the XKB context initialization document.
3. agent-bridge - Command Gateway
What it does: Lets external tools (like web pages) send commands to Claude AI.
Key capabilities: - HTTP server on localhost - Injects commands into Claude's terminal - Serves static files (HTML documentation) - Secure (localhost only, no authentication needed)
How it works: Intercepts Claude's terminal using PTY (pseudo-terminal), multiplexes input from keyboard and HTTP requests.
In the story: agent-bridge received commands from the "Check" buttons and delivered them to Claude for processing.
How They Work Together
┌─────────────────────────────────────┐
│ gtk-2-triage.html (Browser) │
│ [Check Button] clicked │
└──────────────┬──────────────────────┘
│ HTTP POST
▼
┌─────────────────────────────────────┐
│ agent-bridge (localhost) │
│ Injects: /check-bug 1993100 │
└──────────────┬──────────────────────┘
│ PTY stdin
▼
┌─────────────────────────────────────┐
│ Claude Code AI │
│ Orchestrates the response │
└──┬──────────┬──────────────┬────────┘
│ │ │
▼ ▼ ▼
┌──────┐ ┌─────────┐ ┌──────────┐
│foxmcp│ │kb-indexer│ │Bugzilla│
│ │ │ │ │ API │
└──┬───┘ └────┬────┘ └────┬─────┘
│ │ │
│ Browser │ Knowledge │ Bug
│ history │ docs │ details
│ │ │
└───────────┴────────────┘
│
Integrated Response
The workflow:
- User clicks button → JavaScript in browser sends HTTP request
- agent-bridge receives → Injects command into Claude's terminal
- Claude processes → Uses all available tools:
- foxmcp: Browser history, tab management, content extraction
- kb-indexer: Search related investigations
- Bugzilla API: Fetch bug details
- Source code: Search Firefox repository
- Claude responds → Comprehensive analysis in terminal
- User takes action → Continue conversation naturally
Further Reading
Project Components: - foxmcp - Browser automation via MCP - kb-indexer - Knowledge base indexing and search - agent-bridge - HTTP command gateway
External Resources: - Model Context Protocol (MCP) - Claude Code CLI - Ollama - Local AI models