Bug report

What operating system and version are you using?

platform = amzn
version = 2

What version of osquery are you using?

version = 5.18.1

What steps did you take to reproduce the issue?

1. Maintain an osquery.conf whose schedule includes queries against virtual tables provided by Thrift extensions (autoloaded via --flagfile with extensions_autoload / extensions_socket, etc.).
2. Run the upstream profiler against that config, e.g.
   python3 tools/analysis/profile.py --config /path/to/osquery.conf --shell /path/to/osqueryi
3. Observe that profile.py invokes osqueryi with --disable_extensions, so extension tables are never loaded.
4. If extensions are enabled (e.g. by passing --flagfile and omitting --disable_extensions), run with --profile as the stock script does: osqueryi still uses the profile code path in startShell that does not call runner.start() (osquery/main/main.cpp), so the extension manager / normal shell init does not match interactive osqueryi, and extension-backed queries still fail or do not reflect production behavior.
5. For comparison, run the same scheduled SQL from interactive osqueryi with the same flagfile: queries succeed.

Related reports: #6907 (core tables + --profile), #7816 (CLI query vs extension load order; --extensions_require).

What did you expect to see?

One of the following, clearly documented or implemented:

• If intentional: Explicit documentation that stock profile.py / osqueryi --profile are not meant to profile extension-backed scheduled queries, and guidance for supported workflows (e.g. interactive + --extensions_require, or another recommended approach).

• If not intentional: Profiler and/or shell profile path should allow profiling scheduled queries under the same init as normal osqueryi (extensions autoloaded, extension tables available), so performance numbers match what osqueryd would run in production.

Question for maintainers: Is the current combination of --disable_extensions in profile.py and --profile skipping runner.start() intentional for scope/performance, or should this be treated as a bug / feature gap?

What did you see instead?

• no such table: <extension_table> when using stock profile.py (extensions disabled), and/or
• Extension tables still unavailable or behavior diverging from interactive shell when using --profile, even if extensions are enabled via flagfile.