native-profiler-stop reports 'No active native profiling session found' immediately after native-profiler-start (v0.8.0)

[royatluscii]

Summary

native-profiler-stop consistently fails with [Tool:native-profiler-stop] No active native profiling session found. Call native-profiler-start first. even when called shortly after a successful native-profiler-start against the same device_id. The recording session is not being tracked between the two MCP tool calls.

A secondary issue: the bundled default Argent.tracetemplate uses rsrc://templateProcessorTrace and produces trace schemas (kdebug / processor-trace) that don't match the schemas native-profiler-analyze parses for CPU and hangs — so even when a session does survive, the default template returns an empty report.

Environment

• Argent: 0.8.0
• Host: macOS (Apple Silicon)
• Xcode: 26.4.1 (build 17E202), xctrace version 16.0
• Target: iOS 17.5 Simulator, iPhone 15 Pro (UDID A41F04F1-4BC3-4903-BFF4-C7746FA13535)
• Target app: com.omronhealthcare.omronconnect

Steps to reproduce

1. Boot an iOS simulator and launch any app on it via launch-app.
2. Call native-profiler-start with the device's UDID. Tool returns:

   { "status": "recording", "pid": 51559, "traceFile": "/var/folders/.../native-profiler-20260522-134212.trace" }

3. Drive ~30s of interaction (gesture-tap, gesture-swipe, etc.).
4. Call native-profiler-stop with the same device_id.

Expected

native-profiler-stop exports CPU / hangs / leaks XML and native-profiler-analyze produces a populated report.

Actual

native-profiler-stop returns:

[Tool:native-profiler-stop] No active native profiling session found. Call native-profiler-start first.

The trace bundle exists at the path returned by native-profiler-start, but is incomplete — some runs contain an event_data_*.oa, others contain only Trace1.run/RunIssues.storedata (no event data captured at all).

Reproduction matrix

Reproduced with:

• The bundled default template (dist/Argent.tracetemplate → rsrc://templateProcessorTrace).
• A custom template passed via template_path, based on Apple's stock Time Profiler.tracetemplate (which includes coresampler + com.apple.dt-perfteam.hangs).
• A clean state (after xcrun simctl shutdown all + killing xctrace / DTServiceHub / Simulator.app + rebooting the sim + relaunching the app).

Secondary issue: default template uses the wrong schemas

The bundled Argent.tracetemplate archives rsrc://templateProcessorTrace. native-profiler-analyze reports:

> Export warnings:
> - cpu: CPU time-profile export failed — xctrace could not export CPU data from this trace.
>   The trace template may not include a Time Profiler instrument, or the schema name did not
>   match any known CPU profile schema (time-profile, cpu-profile, time-sample).
> - hangs: Hangs export failed — no potential-hangs table found in trace.

Suggestion: switch the default template to one based on Apple's Time Profiler.tracetemplate, which combines the com.apple.xray.instrument-type.coresampler instrument (produces time-profile schema) with com.apple.dt-perfteam.hangs (produces potential-hangs table). That single template covers both of the analyzer's expected schemas in one recording.

Workaround attempted

Created local templates at ~/.claude/argent-templates/ (Time Profiler + Hangs / Leaks + Allocations / Activity Monitor) and passed them via template_path. The schemas are correct in principle, but verification is blocked because the session-tracking bug above prevents stop/analyze from running against them. Confirmed templates are valid by inspecting their NSKeyedArchiver payloads with plutil.

Logs

native-profiler-start →
  { status: "recording", pid: 51559, traceFile: "/var/folders/.../native-profiler-20260522-134212.trace" }

native-profiler-stop →
  [Tool:native-profiler-stop] No active native profiling session found. Call native-profiler-start first.

ls bundle →
  Trace1.run/RunIssues.storedata   (no event_data_*.oa)

[pFornagiel]

Hi @royatluscii,

Thank you for the report. For the first issue - interacting with React Native profiler is sometimes flaky, so to reproduce it properly I will need a bit more context if you're able to share:

• Any further relevant entries from ~/.argent/tool-server.log and ~/.argent/mcp-calls.log during the profiling session
• Used Argent version (argent --version command)
• App details:
  • React Native version
  • Whether expo is used, and if so which version
  • Whether the new architecture (bridgeless) is enabled (RN 0.76+ has new arch on by default)
  • Build type - dev with Metro, or release
  • Whether the app itself crashed, reloaded, or got backgrounded during the ~30s of interaction
  • If possible, you could also check whether there are any underlying errors on the js side during the profiler run.