Emit session configuration event with loaded tools, instructions, and extensions at startup

[sergio-sisternes-epam]

Describe the feature or problem you'd like to solve

The JSONL event stream lacks visibility into what the agent loads at startup — tools, instruction files, MCP connections, extensions, and skills are all resolved before the first turn but never reported in telemetry.

Proposed solution

A new event (e.g. session.config_loaded) emitted once after initialisation, reporting what was loaded. This would allow anyone building observability or cost-analysis tooling on top of the event stream to answer questions that are currently impossible to answer:

• How many tool definitions are injected into the system prompt per turn, and what is their token cost?
• Which instruction files from .github/instructions/ matched the current context, and what is their combined size?
• What fraction of loaded tools are actually invoked during a session?
• Which MCP servers connected and how many tools did each register?

Without this data, users optimising token budgets have no way to measure or reduce the overhead from tool/instruction loading — the largest controllable component of per-turn token consumption.

A suggested payload structure:

{
  "type": "session.config_loaded",
  "data": {
    "tools": [
      { "name": "bash", "source": "builtin" },
      { "name": "github-list_issues", "source": "mcp:github" }
    ],
    "toolCount": 84,
    "instructions": [
      { "path": ".github/instructions/dev.instructions.md", "sizeBytes": 2048, "matchedPattern": "apps/**" }
    ],
    "instructionCount": 2,
    "instructionTotalBytes": 4096,
    "extensions": [
      { "name": "my-extension", "location": "project" }
    ],
    "extensionCount": 1,
    "skills": [
      { "name": "docs-build", "source": "project" }
    ],
    "skillCount": 5
  }
}

Even a minimal version — just toolCount and instructionCount as integers on the existing session.start event — would be a meaningful improvement.

Additional context

• The tool.execution_start event records each tool invocation (name + arguments) but not the catalogue of available tools, so "tools used" can be counted but "tools available" cannot.
• The skill.invoked event partially covers skills but does not address tools, instructions, or extensions.
• Organisations managing token budgets across multiple teams and repositories currently have no mechanism to identify which configurations cause excessive token consumption. This event would close that gap.
• This is a read-only telemetry addition — no changes to agent behaviour, just improved observability.