Sandboxing AI coding tools with Nix and Landlock

Sandboxing AI coding agents with Landlock and Nix

Kernel-level protection for your development environment

Most AI coding agents — Claude Code, GitHub Copilot CLI, Gemini CLI, OpenAI Codex, opencode — run with your full user permissions. They can read your SSH keys, API tokens, credential files, browser cookies, anything in your home directory. If an agent gets tricked by a prompt injection, it can exfiltrate all of it over the network.

This isn't theoretical. The Clinejection attack demonstrated exactly this: an attacker plants a malicious prompt in a PR description or a file in the repo. When the agent reads it, it follows injected instructions to steal credentials and send them to a remote server.

I built ai-cage to reduce this attack surface. It's a reusable Nix flake that uses Landlock with a strict default-deny policy.

How it works

Landlock is an unprivileged Linux Security Module (LSM) — no root required. It lets a process permanently reduce its own filesystem and network access. ai-cage uses landrun as the wrapper.

When you run an agent inside ai-cage, it gets:

• A private HOME directory. Your real home stays hidden.
• SSH agent forwarding without key file access. The agent can use your SSH agent socket, but cannot read ~/.ssh/id_*.
• Restricted network. Only explicitly allowed TCP ports (443 and 22 in aiAgent).
• Nix store execute allowlist. Only package closures you list can execute.
• Inherited, irreversible restrictions. Child processes cannot escape the cage.

Why Landlock instead of containers?

Containers (Docker, Podman, bubblewrap) isolate via mount namespaces. Landlock keeps the same host filesystem/session and denies disallowed access paths. For AI-assisted local dev, this avoids a lot of friction.

No UID remapping surprises. Files created by the agent stay owned by your user, so Git and editor tooling keep working.

Simpler SSH usage. No socket bind-mount gymnastics across namespaces; $SSH_AUTH_SOCK just works when forwarded.

Nix-friendly model. You can expose /nix/store as read-only and execute only approved package closures.

Tradeoff: Landlock is access control, not full environment virtualization. It does not provide PID/network/mount namespaces.

ai-cage vs other Nix jailing options

If you're already in the Nix ecosystem, there are multiple ways to sandbox AI tools. Here's the practical comparison I ended up with:

• ai-cage (Landlock + landrun): best for day-to-day AI coding on your real workspace. Same UID, same filesystem, low friction, no root required.
• jailed-agents (bubblewrap/jail.nix): stronger filesystem illusion via mount namespaces, but more operational friction (bind mounts, occasional ownership/watcher weirdness, more moving parts).
• nix develop / pure shells only: reproducibility and dependency isolation are great, but this is not a security boundary by itself; processes still run with your user permissions.
• NixOS containers / podman-nix setups: stronger isolation layers and cleaner network separation, but heavier workflow and more setup complexity for local editing loops.

For the specific threat model "AI can edit my repo but should not read my secrets," ai-cage is the best balance of security and usability I found.

Using it

Import github:rolfst/ai-cage into your flake and define a cage wrapper:

caged-agent = ai-cage.lib.cage { inherit pkgs; } {
  name = "claude";
  profile = "aiAgent";
  argv = [ "${pkgs.claude-code}/bin/claude" ];
  packages = with pkgs; [ bashInteractive coreutils git openssh curl ripgrep ];

  filesystem = {
    ro = [ "$ORIG_HOME/.gitconfig" ];
    rw = [ "$ORIG_HOME/.config/claude" ];
  };

  env.pass = [ "ANTHROPIC_API_KEY" ];
};

ai-cage ships three profiles (offline, aiAgent, devNet) and supports custom profiles.

Hard-earned lessons

• /dev and /tmp are mandatory for real workloads. Restricting too aggressively breaks common tools. ai-cage now explicitly grants safe required device paths and /tmp access.
• Home-directory sibling file visibility exists in Landlock path traversal. If you allow --ro $HOME/.gitconfig, sibling files in $HOME/ (like .bashrc) can become readable. Subdirectories like .ssh/ and .gnupg/ remain blocked unless explicitly granted.
• Best practice: avoid grants directly in $HOME/; copy required config into the cage state dir or grant a narrow subdirectory path instead.

What it does NOT protect against

I want to be upfront about the limitations:

• Port-only network rules. Landlock cannot filter by hostname/IP.
• Env var exfiltration. If you pass secrets in env.pass and allow outbound network, a compromised agent can still transmit those values.
• No UDP controls. Landlock network restrictions cover TCP only.
• Linux-only. Landlock is a Linux kernel feature.
• Additive permissions in one ruleset. You cannot mark one file read-only inside a read-write directory in the same layer.

The goal is practical blast-radius reduction, not perfect containment. A constrained agent is still far safer than a fully privileged shell.

Code: github.com/rolfst/ai-cage

PlatformCon2025

After a nice walk though London city, I arrived at the st.Paul’s Convene, a great location for the current size of PlatformCon (I do hope they’ll grow even bigger and more important in the near future).

The conference opened with a nice breakfast, beautifully displayed for all participants

But let's take a flashback to the evening before.

Tuesday 17:00 local time, a meeting started. People from all over the world gathered around a round table to talk about platform engineering and A.I., and the platform as a whole, facilitated by the people from Thoughtworks and PlatformCon.

Honestly every conclusion in this relay is my own, since we kept the discussion open and never drove to any settlement.

We spoke about quite a few topics. 2 Still remain fresh in my mind.

The last one was about how to deal with teams that don’t wish to follow the path set out by the platform teams.

I couldn’t escape the notion this was either a forced hypothesis or in a startup (perhaps a scale-up), the organisation wasn’t that well explained but in my opinion in those lifecycle stadiums of an organisation you don’t need a platform. The next day I would learn from another participant in the same room that some startups definitely need a platform, this is because they extensively work with huge amounts of data and calculations on that data that need to be handled by data scientists.

But, in the first phase of an organisation you generally don’t need a platform, yes you’ll need an environment, be it your favorite cloud provider or your own. It's just, the costs are too high for the startup. The startup needs to go fast , push out new features or products like there’s no tomorrow.

Then later the organisation needs to start thinking about and implementing guardrails. Don’t forget a platform isn’t cheap, let alone the endeavor to build one, but at one point the platform will start to provide a return on investment that makes it a necessity. When that is? I don’t know exactly. But when I talk about one of my own clients idea of growing 200 new personnel each month, it was way overdue. Adding more people to the organisation is definitely a scalability issue of the highest order. Not only for that particular enterprise but also for the market as a whole (the enterprise sucks all the professional out of the market).

The other topic was about A.I.. What’s interesting is that a lot of times it’s the business that tells the developers to use A.I., because why? Don’t know.

Jokes aside, often the idea is to remain competitive. We did get the advice to steer away from the cost competitive argumentation. Go for the question the organisation really needs solved and then cost goals will be achieved because of that.

The main day.

The main stage started with a panel. Very insightful and I want to give you this quote from Richey Zachery: `With platformengineering we’re building developer success teams`.

From that moment onward I proceeded to my first workshop: improving ci/cd pipelines. I didn’t like that one. It felt more like a sales pitch and for that I’d go to the booths in the central area.

Speaking of which, there were some excellent companies at those booths. It was easy to engage with them and not all of them were there to do their sales. I had some pretty good conversations that gave me good ideas for my plans with the platformteam at Cohesion.

Anyway, me leaving the workshop early lead me to a chance meeting the exellent Ana Bogdan. We started to discus the previous evening’s meeting and we came down on some conclusions I came up with. I hope she liked my explanations and arguments because she immediately invited me to another (smaller sized) table discussion session. So how could I decline? The prior evening session gave me already great insights, so would probably give me another batch, right? 

It would require me to miss out on some other session, but hey that’s why we went to this event with a small delegation. Dilyano would have to take those honeurs.

In the meantime before the table session, it was time for lunch, to which I must give great kudos. Well fabricated selection of vegan and non-vegan bites.

Afterwards another session about CDE (cloud development environment) that I don’t like to integrate in an IDP. Those things make me feel like with an earlier attempt in the early 0s. Boy am I glad I’m no longer forced to work with WSAD or Vscode for that matter. I strongly believe the developer experience should augment the developers’ preferred workflow and not restrict it. A developer’s workflow (when one is more experienced) has oftentimes evolved around a set of tools according to the preferences of said developer.

Then the table session started and we discussed topics like difficulties for dataengineering, how to deal with finding the right items/topics to find for an IDP. A nice takeaway is that at some point RFCs no longer work, the scale of the enterprise is just too big and the RFCs deal with matters that is not really the problem that an IDP does need to solve. Does this coincide with when a company grows in the size when an IDP becomes a thing (just a curiosity of mine now)? It is better to do surveys and interviews with your developers to collect the adjustments needed.

And finally the topic on, what kind of persons does one need to search for the development team of an IDP. Something we at Cohesion are trying to find out as well.

I must commend Sam and Ana for creating a healthy environment with such fruitful discussions. And,,, I hope to see more like these in the coming PlatformCons.

Lastly, my encounter with Cornelia Davis from Temporal. She and I spoke on something about measurement on the ci/cd pipelines. What we’re lacking is metrics inside the whole pipeline. Vendors like github and gitlab are great but they don’t give us much insights about the jobs we’re running, and where we could improve on those (this was the stuff I wanted to deal with during the work I prematurely left by another vendor). We should push these vendors to allow for (at least) hooks to examine those metrics.

To end this relay: I loved PlatformCon2025, I hope to see you next year.

Typescript Classes exposed as Interfaces

 Suppose you want to do some Dependency Injection magic, or you just want to use the best practice to talk to interfaces instead of implementations.
For some reason language designers made constructs like `interface` and `class` and gave developers the idea that the construct being defined by the interface keyword is the actual type of interface we should program against. 

Well lets humor me for a bit and deal with this type of pattern. We are gonna define interfaces and type aliases and classes for this exercise, but we're also gonna think about naming.
One thing I really don't like about naming conventions is deterring from the actual semantic meaning of a type. With this I mean all these kind of naming conventions like pre- or post-fixing interfaces with an `I`, or post-fixing concrete classes with `Impl`.

brrrr...

A few months ago I learned that you can have code like this:

export const RiskFactor = {    
    Low: 'low',
    Medium: 'Medium',
    High: 'High',
} as const;

export type RiskFactor = keyof typeof RiskFactor;

As you can see we have both a type alias and a const named as RiskFactor.

This is possible because types live in a different context as the const does.

In fact I rather like this I don't want to name the keys anything different than the const because I will use the same type everywhere interchangeably, so it's kinda bothersome to make the types have a different name.

Now comes the kicker:

when I program against an interface I actually want to use the type defined by the interface so and my class is of that type defined by the interface.

when I export a class `Foo` it will also export the type `Foo`. Remember that types and const live in different contexts so the classname `Foo` can both be used as a type and the identifier of the class construct like this:

export class Foo = {};

const bar: Foo = new Foo();

So when I thought of this, I thought that well this way I can actually use the real word to describe the type I want to use for both the interface (aka type definition) and the class:

export interface Foo {
  name: string;
  help(): string;
};

export class Foo implements Foo {}

To my surprise this works too well???

Why doesn't my code editor tell me to implement the missing properties?

to take this further:

 ...
 const bar = new Foo()
 bar.help() // this now fails with a runtime error not with a compiltime error!!!!

Was I doing something wrong? Cuz this fails immediately:

export interface IFoo {
  name: string;
  help(): string;
};

export class Foo implements IFoo {} // compile time error must implement missing properties name, help from IFoo

This fails as well:

  export type Foo = {
  name: string;
  help(): string;
};

export class Foo implements Foo {}

This fails with the following warnings:

• Duplicate identifier 'Foo'. typescript (2300)
• Class 'Foo' incorrectly implements interface 'Foo'.
  Type 'Foo' is missing the following properties from type 'Foo': name, help typescript (2420)

What I recon from this is that a class exports its definition as an interface and conflicts with type.

The reason I think why the duplicate name of the interface with class does work is due to the typescript feature of interface merging.

When you have 2 or more interfaces with the same name, yes this is allowed in typescript, it merges the definitions of these interfaces into one. I think classes and interfaces behave in the same way and that's why we don't have a compiletime error when using classes and interfaces with the same name.

But now the practical part. 

This doesn't make any sense. I want the compile to direct me with helping me syncing the concrete implementation with the interface(s) it implements, but now typescript suddenly says to me: "Hey dude it's all up to you now, you're back in javascript-land except you aren't cuz interfaces aren't part of the javascript specifications. Well your problem not mine....."

I guess I still have to deal with types that don't mean anything or classes that have a suffix that is just noice.

The use of TypeScript. Why?

I am searching for the real use of TypeScript.

disclaimer: I am going to write TypeScript as Typescript, just as a heads-up for the critical reader.

In my life as a developer I tried to understand why people want to make certain choices for languages and tools. I don’t want to go pick a tool or language just because people order me to do that. I always wonder why they do that. Is it policy or is did they actually think of it.

I mean I understand why people want to use Typescript from certain perspectives.

• The use of types,
• My framework uses typescript (Eg. Angular),
• The ease of use of OOP programming,
• My Java developers can immediately start programming because of the familiarity Typescript has with Java,
• Typescript allows me to use my tooling like autocompletion,

Of all these arguments I can just as easily say a counter argument. For me the only really valid point is the second argument in above list.  

When you choose a framework where all the documentation is written in a language it is hard to break out of that language.

Let me try to explain why I am not convinced in these arguments.

Types

In using good programming (mind you I say programming not Typescript) we make use of Types (often seen as objects in OOP).Types are defined by a contract not by using a keyword that loses its purpose in runtime.

The use of types in Typescript are only used to satisfy the compiler, but then we added this compiler as a language tool (like any compiler). But here it comes, the angular compiler is not so much as a compiler but more of a transpiler. It transforms the Typescript to Javascript and it erases all type information once the resulting code is left as Javascript. Also what I have found is that the use of types is often neglected as I will argue in a later reasoning here.

I like dynamic languages. The give me an feeling of productivity that I cannot achieve with statically typed languages like Java (or Typescript).

I like to work with the mantra: 

if it walks like a duck and if it talks like a duck, it's probably a duck

For me this is all about the contract. 

When the object in question does not follow the contract it just isn't the type we need in this context. If we use Typescript to define our types we know it is fine during compilation however in runtime there is no such confirmation or construct that we are using the expected type. The only way to way to verify this is to test. 

Why do I say we have no such confirmation in runtime? Well too often I see developers make use of the 'any' type. 'any' basically says: I don't know what type we're using here but trust me it's gonna be alright.... 😑

This 'any' and the loosing of typing in runtime can give us false safety.

*Update november 27th 2021,

The latest versions of Typescript have undergone some much improved additions to the typesystem. This makes the use of types much stronger and I dare say even better as you can no even use types (to some degree) in such a way it will contain logic that foregoes the use of unit tests. This means the compiler is able to apply logic to the output of some functions so the functions no longer need to be tested. I even saw a usage of this that is able to solve sudokus at compile-time. Though this seems great it costs a whole lot of understanding new ways to solving solutions programatically. The complexity is really big when using this approach and leads to other costs during development. Eric Elliott calls this

Typing overhead. In my opinion if you really want to use typesafety in your web development you should thing of languages like ReScript. ReScript offers typing but due to superb type-inference you will hardly notice this when creating your code, but your IDE and compiler will still be able to confirm to your used types.

*end update

Frameworks

Currently amongst the most used frameworks in the enterprise is Angular. Angular is written in Typescript. All the documentation is written in Typescript. All the examples likewise. I understand this as a valid point in using Typescript. It makes your productivity much higher especially when you program and use the likes as stack overflow and the official examples as your way to solve your programming issues. No questions asked no answers given. I take this as fact. However, I still wonder why these frameworks would be written in Typescript in the first place.

OOP

Typescript promotes the use of object oriented programming. I agree. Since Typescript is modelled after C# and Java, it promotes the use of the class construct and hence object constructs. Typescript however also is a so called supertyped javascript it allows you to write plain javascript without the added features Typescript has. The class construct is not the classical construct as we know from Java and C#, basically it is syntactic sugar over the prototypal inheritance structure Javascript offers.

In fact ES6 offers this construct so it is not even exclusive to Typescript.

Now I favor the use of functional programming over oop, while this is not entirely so. I really prefer the use of a hybrid approach of using both functional and oop in my code.

I see the use of services best described in a functional pattern, not in the way Java promotes. Java services are often a collection of related methods combined in an object. To me this is more or less a Façade without the usage of multiple delegated extra components. 

Coming from a different language

I heard a few of my peers tell me: "well thanks to Typescript my java developers were able to code for the frontend because the language is practically the same."

There is so much wrong with this argumentation, I hardly know where to begin. Let me try though.

Being able to program in another language because the syntax is so familiar is like saying you can use oranges for your apple pie because they are both fruits and hang both on a tree and you have to peel their skin off.

Go and tell an average Java programmer to start programming in C# because the syntax is nearly the same. It just doesn't work that way. Sure the programmer is able to produce some code, but let's call it at that ok? Tell a windows engineer to setup a linux server, they are both servers and have a cli. I think you got my meaning.

apples and oranges who cares?

Typescript is just no Java. Don't pretend it is because of syntax similarity. We hide behind a layer of semantics that we try to map on javascript. 

We hide the concept of the actual workings of prototypal inheritance in Typescript or even in ES6 for that matter. The interface semantics are different in Typescript than in Java. In Java an interface is meant to be a contract, in Typescript it is meant as a struct a type without any specific behaviour. Though the documentation claims the interface to be a contract as well, I even see this construct in a Typescript interface:

[propertyName: string]: any;

What this allows you to do, is to basically say: any property you add to this interface is allowed.

Object literal? Any? (pun intended).

We basically leave the contract so wide open it basically becomes void.

I just think you just need to take the fear of using a different language away from the Java developer Typescript is just another trick to persuade the Java developer to become a frontend developer, but it leaves the developer in no-mans land. 

The real solution is to just educate the Java developer in javascript. But don't fool the developer. It's just not right. Either point out he has to do the dam job and suck it up or stay out of webdevelopment, just be honest.

Tools

Typescript allows me to use tooling for my productivity.

Well this seems to me it's the other way around. Aren't tools used to enhance our productivity? Shouldn't tools provide a means to make our work easier? In that way Typescript is a tool but so is javascript. And this is exactly my question: Why should I use Typescript? 

Visual Studio is an editor that allows me to use plugins to enhance my writing of code. but it also allows me to enhance me my writing of javascript code, not just Typescript.

Personally I have a multitude of tools I write my code in. I am a vim user (neovim for that matter). I have found lots of ways to increase my productivity in that editor.

Do I want to be convinced to use Typescript?

Well I certainly want to understand why I should use Typescript over javascript. I just don't see it.

I would be very happy if someone could point out to me what I am missing. I want to share knowledge and I certainly will try to provide this found knowledge to others in helping them.

For references I also direct you too these documents

https://itnext.io/why-use-typescript-good-and-bad-reasons-ccd807b292fb

https://medium.com/@wittydeveloper/typescript-the-honest-trailer-ae19e7bc0f7e

https://www.typescriptlang.org/docs/handbook/interfaces.html

Becoming DevOps

I've been working on creating development environments a while now and my current employer wants to have a quick way of setting up a development environment for the projects that we do.
Since I've worked with Vagrant before it befell to me to do the setting up of it all.

Vagrant is a tool that can make use of virtualisation software like Virtualbox or VMWare. It provides means to run the vm image (box) with a provisioned state specifically for your (development) needs.

I started by making use of packer. Packer allows me to setup a vagrant box in much less time than it would take me to if I used Vagrant itself for creating boxes.
Packer allows you to select the iso and the virtualisation software and also provides hooks to provision the box with the tools you would need to do your job once you start developing on the box within your project.
This provisioning is obviously the hard part and needs the play-rewind-repeat cycle to really put the stuff on the box that you want.

Let me tell you what I did without the repeat cuz of course I did it right in one time *cough*.

I found a set of packer templates on the web that allowed me to jumpstart the creation of the boxes.
Although I might now use PuPHPet with some adjustments I learned quite a bit about provisioning.
First the basics:
I modified the template I needed and I added an extra script for my provisioning needs.

I added this script in my template.json.

Then I added the puppet locations to my template.json within the provision section:
  {
"type": "puppet-masterless",
"manifest_file": "/tools/vagr_build/puppet/manifests/default.pp",
"manifest_dir": "/tools/vagr_build/puppet/manifests",
"module_paths": ["/tools/vagr_build/puppet/modules"]
    }
Obviously I have my build environment in tools/vagr_build as you can see here, you might have other locations.
I also make use of puppet-masterless because we do not have a puppet server within our company and I didn't want to invest time to set that up as well.

Now comes the big part, the real provisioning. I created my provisioning command in the default.pp file
I first install some base packages and mysql with apache. Then comes the PHP part and this part needed some extra configuration
To configure PHP correctly I needed to create a php.ini within /etc/php5/conf.d/ I updated its content using a tool called augeas Puppet knows how to use this but it needs to be installed serparately, so I did that with the base packages.
Note the context within a augeas part starts with /files/ this is a nessecary part to edit files.

From here I made my box file:
> packer build -only=virtualbox-iso .\template.json
and once this was done I did
> vagrant box add ubuntu_12_php53 .\ubuntu-12-04-x64-virtualbox.box
to place my box with vagrant

Later use of this box is just how you would normally use a vagrant box.

Debugging python with vim in a virtualenv

Yay I finally got it working my debugging of a python script with Vdebug in vim
Vdebug is a vim plugin that lets you debug all kinds of scripts/languages in vim.
It supports these languages:
Python
Perl
PHP
Ruby
Node.js

At work I use it to debug Perl code and I wanted to use it to debug my python code for personal projects.

the key is: pip install  komodo-python-dbgp within your virtualenv once that is done it will create the executable pydbgp in your virtualenv. so you can launch in vim vdbug and then in the shell:

pydbgp <script>

Working on a new web project

Ok, so I started working on a web project for a friend of mine.
I want to work with some new stuff so I decided to implement this application with some neat new technologies (well new for me anyway).

All the while I have been dabbling with some stuff during the years now and I came up with a basic installation to get my workflow ready.
For this I am making use of a script that I execute to setup my projects environment:


This installs an isolated python environment and an isolated node.js environment for webdevelopment.
The script will also offer the option to work either with a Yeoman workflow or a Brunch based workflow.


When I start my work I just use another script that will launch my work environment in correct settings.
For that I make use of tmux a screen multiplexer that enters in the activated virtualenv:


I've decided to build this all with Angularjs in the frontend and flask or django on the backend. The backend I will decide later on.
For the workflow I will use Brunch because it is a fairly basic webapplication and the speed of usage in a Brunch workflow outweighs the flexibility/complexity of the Yeomand/Grunt  configuration.
I made a skeleton to work with coffeescript and Angularjs and made that available on github.

I will provide details of my progress.

VLC and AirportExpress

At work we got our hands on an Airport Express. So the first thing of course is "MUSIC".
Well we do have some people here that want to use iTunes. But for personal reasons I don't like iTunes.
So I normally use VLC like any sane person would do :) But while all of my co-workers were laughing at me cuz i couldn't join with the music streaming.
Not taken aback I was strolling the internet to find if there was a solution of streaming to Airport. There was a program called Airfoil but hey I'm dutch so i really don't want to pay for programs unless necessary. At the VLC forums i stumbled on a post by crzyhanko and he posted some great code you can put in the standard streamchain field of the VLC player:
#transcode{acodec=alac,channels=2,samplerate=44100}:raop{host=<ip address of airport express>,volume=175}
It works :D so who is laughing now

SQL remove of constraints

Note to self:

when doing large imports using a sql script in oracle. here's how to remove constrains and then enable them after insert:


This code is useful to disable the constraints in the database.

set serveroutput on;
begin
  for c in (select constraint_name, table_name from user_constraints where constraint_type='R') loop
    execute immediate('alter table '||c.table_name||' disable constraint '||c.constraint_name);
  end loop;
end;
/

the '/' at the end lets sql developer know that this is the end of an inline pl/sql script

then insert the normal sql insert script and when done include this code:

begin
  for c in (select constraint_name, table_name from user_constraints where constraint_type='R') loop
    execute immediate('alter table '||c.table_name||' enable constraint '||c.constraint_name);
  end loop;
end;
/
-- SHOW ENABLED --
select constraint_name, status from user_constraints where constraint_type='R';

When the last line still shows disabled constraints the data is corrupt.

Blobs of type String can be inserted via a workaround:

declare myBLobVar varchar2(32767) := 'paste string here' ;
begin
  update tableWithBlob set blobCol = myBlobVar where id = blah ;
end;

Eclipse Templates

Templates are a usefull thing when working with code as we know.
A simple template is a simple thing to do but using an import is a different beast.

so here is a example to make sure that the import is also included in the java file.

/** Tapestry render phase method. Called before component body is rendered.*/
@BeforeRenderBody
public void beforeRenderBody(){
${cursor}
}
${:import(org.apache.tapestry5.annotations.BeforeRenderBody)}