New Transparent capture is in preview. Record every app's traffic with no proxy configuration, on Windows, macOS and Linux. Learn more

processIdFilter Filter

Select exchanges that originate from a single local process identified by its operating system PID, useful for isolating a target program on the same machine.

processIdFilter is the most precise way to scope a Fluxzy rule to one local program, but a PID is a short lived value. Use it for quick experiments, and reach for processNameFilter whenever you need a rule that keeps working across restarts or across multiple instances of the same binary.

When to use this filter

Reach for processIdFilter when several applications are sharing the same machine and you only want to act on traffic from one specific instance. Because the filter matches a single PID, it is best used in short lived debugging sessions rather than long running automation.

Typical situations:

  • Isolating a noisy browser tab process or a worker child that has its own PID.
  • Debugging a single CI step where the runner spawns one known command at a known PID.
  • Sandboxing one instance of a tool while leaving sibling instances untouched.

Process tracking must be enabled, and the connection must originate from the local host. If you need to match a tool by name, or to follow restarts where the PID changes, prefer processNameFilter.

Real world examples

Capture traffic from a single PID into a dedicated file

Send every exchange initiated by PID 4242 to a separate fxzy capture so you can analyse it in isolation.

rules:
- filter:
    typeKind: ProcessIdFilter
    processId: 4242
  actions:
  - typeKind: CaptureSessionAction

Tag exchanges from a known worker process

Apply a tag to every request issued by a long running daemon so you can pivot on it later in the UI.

rules:
- filter:
    typeKind: ProcessIdFilter
    processId: 8123
  actions:
  - typeKind: ApplyTagAction
    tag:
      value: worker-daemon

Reject everything that does not come from a sanctioned PID

Invert the filter to block any local exchange that is not produced by the explicitly allowed process, a quick way to enforce a per process allow list in a test sandbox.

rules:
- filter:
    typeKind: ProcessIdFilter
    processId: 1234
    inverted: true
  actions:
  - typeKind: RejectAction

Reference

processIdFilter

Description

Select exchanges initiated by a process with the specified process ID. Process tracking must be enabled and the connection must originate from localhost.

Evaluation scope

Evaluation scope defines the timing where this filter will be applied.

requestHeaderReceivedFromClient This scope occurs the moment fluxzy parsed the request header receiveid from client

YAML configuration name

processIdFilter

Settings

The following table describes the customizable properties available for this filter:

Property Type Description DefaultValue
processId int32 The process ID to match 0
inverted boolean Negate the filter result false

Example of usage

The following examples apply a comment to the filtered exchange

Filter traffic from process with ID 1234.

rules:
- filter:
    typeKind: ProcessIdFilter
    processId: 1234
  actions:
  - typeKind: ApplyCommentAction
    comment: filter was applied

.NET reference

View definition of ProcessIdFilter for .NET integration.

See also

This filter has no related filter

Frequently asked questions

Why does the filter never match my remote traffic?

processIdFilter only works for connections that originate on the same host as Fluxzy. Remote clients have no resolvable local PID, so the filter is skipped for them.

What happens if the process exits and a new one reuses the PID?

The match is purely numerical, so a recycled PID will be matched too. Use processNameFilter if the identity of the program matters more than the kernel handle.

Does this work on Linux, macOS and Windows?

Yes, on every platform where Fluxzy can enable process tracking. The OS specific lookup is performed once per connection.

How do I find the PID I should target?

Use the platform tools (Task Manager, Activity Monitor, ps, lsof) before the request, or read it back from the Fluxzy UI which reports the resolved PID on each exchange.

Learn more about Fluxzy rules