Post-processing command

1. What it is

The post-processing command is a command line of your choice that pepito runs after each processing of a recording (transcription, then minutes). pepito hands it the recording through environment variables and reads nothing of what it produces. It is generic: it can start any tool, an AI tool or a plain script. Settings, Behaviors, After processing, has the switch, the command line and a Test button.

Privacy: pepito passes the recording's files to this command, on this Mac. What the command does with them (sending them to an AI tool or a server, for instance) is up to the command. The statements elsewhere on this site about what stays on your Mac describe pepito without such a command. A command that sends them to a remote service fits a Mac that is allowed to reach that service.

Warning. The command runs without asking you, with pepito's permissions. If it starts an AI tool, a transcript can contain instructions aimed at it: allow that tool only what it needs.

2. The contract

When it runs

After each processing that ends without failure: a recording you stop, a retry or rerun, an audio or transcript import, a merge, an audio edit (a split starts two runs, one per recording). Both conditions must hold: the transcription succeeded, and the minutes succeeded or were not started because no language model is set up. It starts once the processing is over, after the automatic tagging that can follow the minutes, so the command sees the tags. Nothing starts for a processing that failed or was cancelled, nor while a recording is in progress.

It does not run when an AI tool regenerates the minutes or replaces the transcript through MCP, nor for a rename, a title suggestion, the Auto-tag action or a direct edit of the minutes (including restoring a previous version). A command that writes back through MCP therefore cannot start itself again. The switch and the line are read when the processing ends: it runs only if the switch is on and the line is not empty, and turning it on later does not catch up on earlier recordings. The command does not need a license and runs whether MCP is on or not; pepito does not know whether the command uses it.

Call and variables

Requires pepito 26.61 or later.

The call (/bin/sh -c, the working folder, standard input), the variables of the recording (PEPITO_RECORDING_ID, PEPITO_BASE_PATH, PEPITO_METADATA_PATH, PEPITO_AUDIO_PATH, PEPITO_SRT_PATH, PEPITO_SUMMARY_PATH, PEPITO_NOTES_PATH, PEPITO_GUIDELINES_PATH) and their presence rules are common to your three commands and described on Commands. For this command, PEPITO_TASK is post_processing, and PEPITO_REASON says why it runs (table below). The recording's variables are always set, as a post-processing run always concerns a recording. PEPITO_SUMMARY_PATH is absent when there are no minutes (no language model was set up).

There is no MCP variable and no language variable (the language is in recording.json). A command that wants MCP goes through the configuration of the AI tool it starts, which you made with the "Connect an AI Tool…" assistant: pepito does not pass the endpoint or the token.

The paths are valid when the run starts. If you edit the audio, regenerate the minutes or rename the recording while the command runs, the paths can be out of date; the new processing queues another run. A command that wants the current state reads it again through MCP.

Reason

The list can grow: a command tolerates a value it does not know.

Output, failure, time limit

pepito reads nothing of what the command produces, except in the output of the Test button, and stores nothing in recording.json. A non-zero exit code is a failure, and pepito shows a notification (always on, no setting); stopping a run, deleting the recording and quitting pepito are written to the log only. Output, failure messages, stopping and the 20-minute time limit follow the rules of Commands.

One command at a time

All runs, for all recordings, go through one queue, one at a time, in arrival order. A new processing of the same recording queues another run; runs are never merged. The recording's inspector shows a "Post-processing" row while a run is queued or running, with a Stop button. pepito does not lock the recording: the command can write through MCP while you work.

3. Deployment with MDM

Preference domain: fr.sodadi.pepito. Keys:

• postProcessingCommandEnabled (boolean): turns the command on. Default false.
• postProcessingCommand (string): the command line, run by /bin/sh -c. Default empty; an empty line runs nothing, whatever the switch.

Your IT department deploys the script and the tool it starts. A shared command can send the recordings to an internal language model, for instance. Example of a configuration profile payload, as an Application Custom Settings payload; adapt identifiers and UUIDs:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>PayloadType</key><string>Configuration</string>
  <key>PayloadVersion</key><integer>1</integer>
  <key>PayloadIdentifier</key><string>com.example.pepito.postprocessing</string>
  <key>PayloadUUID</key><string>11111111-1111-1111-1111-111111111111</string>
  <key>PayloadDisplayName</key><string>pepito post-processing command</string>
  <key>PayloadContent</key>
  <array>
    <dict>
      <key>PayloadType</key><string>fr.sodadi.pepito</string>
      <key>PayloadVersion</key><integer>1</integer>
      <key>PayloadIdentifier</key><string>com.example.pepito.postprocessing.settings</string>
      <key>PayloadUUID</key><string>22222222-2222-2222-2222-222222222222</string>
      <key>postProcessingCommandEnabled</key><true/>
      <key>postProcessingCommand</key><string>"/usr/local/share/pepito/post-process.sh"</string>
    </dict>
  </array>
</dict>
</plist>

The value is not locked. The profile sets a default, but a user can change the switch and the command in Settings. If you need to guarantee that recordings go only to your command, control it outside pepito as well.